Create a browser node test that syncs with a local development node

[expenses]

At the moment, the browser node is a pain to maintain, and breaks frequently (#6457 etc). As we can't test the browser node fully without syncing with another node, and as syncing with flaming fir or another permanent testnet is unreliable, we need a test that tries to sync the browser node with a temporary dev node that's spun up in CI.

Here is a rough idea of how it would work:

1. A --dev node is started up with --listen-addr /ip4/0.0.0.0/tcp/30334/ws.
2. The dev node's peer id is fetched.
3. A headless browser test is started, with the peer id as an argument.
4. We test to see if the test syncs a few blocks within a certain time frame (i.e. 1 minute).

Here is a branch that I've started writing this on: https://github.com/paritytech/substrate/tree/ashley-browser-sync-test (based on #6457).

Unfortunately, when I run a node with cargo run -- --dev --validator --listen-addr /ip4/0.0.0.0/tcp/30333 --listen-addr /ip4/0.0.0.0/tcp/30334/ws, the browser node keeps connecting and disconnecting: https://gist.github.com/expenses/212d7c4d9e82c893ace412c99f4764f4, so we need to sort that out first.

[expenses]

@bkchr @tomaka

[tomaka]

The dev node's peer id is fetched.

Rather than fetching the peer id, an easier way would be to pass --node-key to the node to inject a predefined peer id to it.

[tomaka]

the browser node keeps connecting and disconnecting: https://gist.github.com/expenses/212d7c4d9e82c893ace412c99f4764f4, so we need to sort that out first.

We need the sync logs of either the local or the remote.
The sub-libp2p logs of the remote might also help.

[expenses]

Here are the logs of the native node: https://gist.github.com/expenses/7bac9e5bdae1a9ddd32461e5a8c12740.

2020-06-22 17:12:06.755 tokio-runtime-worker TRACE sync Peer is on different chain (our genesis: 0xd5bf…814c theirs: 0x2324…1320) is probably the important part 😉 this should probably be a warning.

[bkchr]

If you added the native node as bootnode to the light client, it should print the warning that the bootnode is on a different chain.

You will need to export the chain spec of the native node and import it in the light client to make it work.