Add an option to run tests using separate node for proxying calls to eth network

[dshulyak]

Problem

There are two ways how status rpc client can be used.
With "upstream" node, separate geth node, part of rpc requests will be offloaded to that node.
Without it - all requests will go to the local LES node.

For some operations, it is critical to validate both of this paths. For instance to fix this problem locally, #538, - I added https://github.com/status-im/status-go/blob/develop/geth-patches/0008-tx-pool-nonce.patch to our geth implementation.
But with "upstream" this problem is not fixed, and I expect it to be fixed with #538 which we need to verify.

Therefore, we need a reliable way to reproduce such issues and confirm that they are fixed.

Implementation

There should be an option for tests to use separate geth node. Probably it makes no difference if the node will be LES or full ETH, but it needs to be checked.

There are two options how to start such node:

• a separate process, maybe docker container, with upstream geth code. It will provide better isolation and relevant test results.
• spawn geth node in the test process, with code from our repo. the problem that it will include local fixes, which may give us false positives in tests.

Communication should be over htttp/websocket/unix socket endpoint, not inproc.

Acceptance Criteria

Option to run an e2e test with "upstream" geth node

[divan]

Nice idea. That will also require management of all aspects of that container/geth instance (waiting for sync, keeping up to date to latest version etc), but that definitely will make tests more reliable.

[dshulyak]

This is partially implemented in our codebase. Sorry for confusion