Rename provider streams, notify provider of stream failures

[rekmarks]

This PR renames the streams we use to connect to the inpage-provider, and ensures that the provider is notified when the streams connecting the content script to the MetaMask background fails.

Currently, the provider streams have very generic names. Although it is unlikely that this would cause problems in production, we could encounter naming collisions with other extensions that use our stream packages in production. In any event, it doesn't cost us anything to rename the streams. IIRC, the last time I suggested we do this, @Gudahtt mentioned that it could be breaking for e.g. sites that bring our provider to get around the Firefox CSP issue where injection fails, but we are shipping so many breaking changes that those folks will have to upgrade anyway.

Now, for the second change, if the extension background process is restarted, all pages will have to be reloaded in order for the provider to establish its connection to the new background process. Historically, three warnings about MetaMask stream failures have appeared in the page console when this happens. In these cases, the provider should emit the disconnect event. However, this never happened in practice, because it was the content script streams that failed, and the provider was never notified of this. We improve upon this state of affairs by informing the provider that the connection to the background is lost, so that it can emit the disconnect event, and the user can reload the page.

Corresponding inpage-provider PR: MetaMask/providers#120

[metamaskbot]

Builds ready [f3700ca]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• dep viz: background
• all artifacts

Page Load Metrics (355 ± 33 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	29	81	51	17	8
		domContentLoaded	273	515	353	70	33
		load	275	516	355	69	33
		domInteractive	273	514	353	70	33

[rekmarks]

We use postMessage directly here because, by the time we want to send this message, the streams will have been torn down because they are all pump:ed together, and pump tears them all down if even a single stream fails.

[metamaskbot]

Builds ready [57ce6bb]

• builds: chrome, firefox, opera
• bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
• dep viz: background
• all artifacts

Page Load Metrics (364 ± 40 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	29	92	53	20	9
		domContentLoaded	276	538	363	82	39
		load	277	540	364	82	40
		domInteractive	276	538	363	82	39

[brad-decker]

Couple questions, but appears to be working and LGTM

[brad-decker]

Q: Was this change made simply to clean up the log output (Not prefixing it with the connection lost message?)

[rekmarks]

Yeah; I just decided that these were cluttering the user's console with warnings for little benefit, and so downgraded them to debugs.

[brad-decker]

Why do we no longer need to know that the dom is ready?

[rekmarks]

I think we needed it in the past because we pulled metadata in this script instead of in the inpage provider. Now, we were just calling start, which first set up the streams, and then waited for the DOM to be ready to do, nothing.