Remove Babel 6 from internal dependencies

[rekmarks]

This PR updates our internal dependencies to remove babel@6 from our internal dependency graph. The only dependency requiring babel@<7 or babelify@<10 now is ganache-core, a dev dependency.

Everyone developing on/with the extension should see less build issues, and we should be able to use yarn/npm link now, or for a time.

The affected packages (and the corresponding PRs) are:

1. Move Babel/Browserify to devDependencies, update packages obs-store#8
2. Escalate errors on RPC responses json-rpc-engine#18
3. Update packages, Babel 7, Node 10 eth-json-rpc-middleware#12
4. Update packages, Babel 7, Node 10 eth-json-rpc-infura#13
5. Update packages, Babel 7, Node 10 eth-json-rpc-filters#9
6. Update packages, Babel 7, Node 10 eth-block-tracker#41
7. Update packages, Babel 7, Node 10 web3-provider-engine#318
8. Update packages, Babel 7, Node 10 KeyringController#32
9. Update packages, Babel 7, Node 10  eth-token-tracker#13
10. Update packages, Babel 7, Node 10 providers#5
11. Update packages, Babel 7, Node 10 core#145
12. Remap request IDs to prevent issues from duplicates, 3.0.2 web3-stream-provider#3

All PRs are merged, all packages

[rekmarks]

Currently failing e2e tests.

Chrome: throws on this line of web3-stream-provider: https://github.com/kumavis/web3-stream-provider/blob/master/index.js#L54

Firefox: Timeout Error with reference to TimeoutError: Waiting for element to be located By(css selector, .unlock-page__link--import)

I can reproduce the Firefox error but not the Chrome error locally. Branch was rebased onto develop today (8/20/2019).

[kumavis]

@rekmarks this could be caused by non-unique request ids if they are not going through an id-remapper

multiple requests with matching ids start, response for one deletes the stored callback, then the second response comes in and the callback is missing

potential solutions:

• incomplete: validate that if a request comes in for an id when we're already waiting on that id, through at request time.
• better: ensure we're using an id-remapper
• alternate: drop web3 stream provider for something like dnode that tracks request response for us

[Gudahtt]

I'm seeing this error locally as well, on both Chrome and Firefox.

Maybe one of these dependency changes is causing this duplicate request id issue? It wasn't clear to me what might have triggered this change.

[rekmarks]

@Gudahtt I'm now able to repro as well. The Timeout Error appears to result from the web3-stream-provider error. Currently testing the hypothesis that we need to put an idRemapMiddleware somewhere.

[rekmarks]

I believe I've identified the RPC requests with the duplicate IDs: https://github.com/MetaMask/eth-block-tracker/blob/master/src/polling.js#L69

Clearly these requests are passed through the extension UI's StreamProvider here: https://github.com/MetaMask/metamask-extension/blob/develop/app/scripts/ui.js#L129-L142

The question is, how are we processing these requests? I can't find the RpcEngine for the background connection on the UI-side. Adding an idRemapMiddleware to the background's provider connection middleware stack (see here and here and here) does nothing as the error is occurring in the UI.

[rekmarks]

Added id remapping to web3-provider-stream, solving the duplicate id error: https://github.com/rekmarks/web3-stream-provider

Now something else broke, and upon review, my suspicion is that transactions are being created with undefined IDs, given that this error is thrown: https://github.com/MetaMask/metamask-extension/blob/develop/ui/app/ducks/confirm-transaction/confirm-transaction.duck.js#L353

It could be that because our now JSON RPC 2.0-compliant json-rpc-engine is escalating RPC errors, functionality relying on past behavior may be breaking.

Edit: The erroring function was called in componentDidMount of confirmTransaction. At the time of mounting the transactionId could still be undefined in some cases. Solved it by wrapping the function call in a condition.

[rekmarks]

Ready for review.

e2e tests are passing with the same errors as for #7029

Still needs QA @tmashuang

@whymarrh, I don't want to mess with your RC, but?

[whymarrh]

A few comments inline. Also can we rebase this on the latest develop?

[Gudahtt]

Looks good!

This has been addressed