Move stream functionality from BaseProvider to new StreamProvider

[rekmarks]

The constructor of the BaseProvider expected a duplex stream, and the class as a whole contained a considerable amount of logic specific to streams and stream handling. This PR extracts this and other dependent functionality into a new class, StreamProvider, which is now extended by MetaMaskInpageProvider, while BaseProvider is made abstract. This will be useful for replacing internal legacy providers (which do not always / ever use streams) with EIP-1193 equivalents throughout the MetaMask codebase.

This PR should be completely non-breaking except for the changes made to the BaseProvider class. In addition, createExternalExtensionProvider, MetaMaskInpageProvider, and initializeProvider should have no behavior changes at all.

In detail, this PR:

• Converts BaseProvider to an abstract class, and moves all stream-specific functionality into a new class, StreamProvider
• Moves BaseProvider tests to the StreamProvider tests, adds an initialization test case
• Adds optional rpcMiddleware parameter to BaseProvider
  • Middlewares previously instantiated and pushed inside of BaseProvider are now instead passed as constructor parameters to StreamProvider and MetaMaskInpageProvider as necessary.
• Moves networkVersion-related logic from the BaseProvider to MetaMaskInpageProvider, while continuing to rely on the networkVersion having the value of 'loading' to detect when we are mid-network change in the StreamProvider (and by extension its child classes).
• Updates the Jest config, adds jest-it-up and minimum coverage requirements

[mcmire]

This is something that we've obviously been thinking about for a while and have wanted to do, so thank you for doing this. I took another look at EIP-1193 to verify that BaseProvider satisfies the minimum requirements and didn't see anything that stands out. I also like how minimal BaseProvider is now. A few questions/suggestions below, but overall looks good to me.

[mcmire]

One more thing, then I'm good!

By the way one thing I've noticed is that you've changed all of the default exports to named exports. That isn't the first time I've seen that pattern, so I'm curious — what are your thoughts? What are the benefits you see using named exports vs. default exports? Are there any scenarios in which we would still want to use default exports?

[rekmarks]

@mcmire, regarding named vs default exports, I think default exports make sense when you have a module that exports a single thing for which the name isn't that important. As soon as you are exporting multiple things from the same file, it's probably time for named exports. Mixing default and named exports isn't really that harmful in TypeScript IMO, but there's not really any benefit either. In JavaScript, I've found the practice to be actively harmful and confusing, because it's easy to mess up your imports and/or exports when your editor doesn't tell you about it.

The reason I made the change in this PR is because I made a change that caused a file to export two things instead of one, and then I just went through and removed all default exports except one, which is an internal log / error message utility (src/messages.ts).

On second thought, default exports also have the weakness of being importable under different names, which can be very confusing in large code bases. For our single message utility it doesn't matter, but it's been a real pain in the ass to deal with in the extension historically.

[mcmire]

Okay, thanks for the explanation, makes sense!

[mcmire]

Two more things!

[mcmire]

LGTM!

[mcmire]

LGTM!