(Feature) Add support to communicate with networks by RPC

[akolotov]

Currently parity-bridge assumes that full nodes of networks are configured on the same system where the bridge is run. Therefore it communicates to the nodes by using IPC. This cause several limitations:

• Requirements to the network bandwidth and the system performance/capacity should be quite high: the system must have enough space to keep two blockchains and must verify all new appeared blocks. So, it means that maintaining one bridge instance withing the cloud could be quite expensive solution.
• The availability of the bridge software depends on the reliability of the particular Ethereum network client software. If an Ethereum client is not operaing (e.g. it crashes accidentally), the bridge software is not operating as well.

The way to avoid these limitations is to introduce ability for the bridge to communicate to full nodes through RPC. It will increase responsiveness of the bridge slightly which should not cause big issues due to the current nature of transactions confirmation mechanism used in the blockchain (there is no strict guarantee of a transaction inclusion into the next block).

Changes required:

---

1. Change bridge/src/config.rs to
   • support the configuration parameters _rpchost and _rpcport;
   • introduce the parameter keystore to keep the path to the directory where files with private keys are stored, this parameter is not subordinated to any section of the configuration file since it is common for entire bridge;
   • extend sections [home] and [foregin] with parameter password which contains path to the file with password to decrypt the corrsponding key file to extract the private key of the account responsible for signing transactions related this side of the bridge.
2. Change bridge/src/app.rs to provide the ability to connect through RPC. The following logic of connection channel selection should be implemented: if the parameter ipc is specified the IPC connection must be setup even if _rpchost is specified. If _rpchost specifed but there is no configuration for the parameter _rpcport the port 8545 is used by default.
3. Extend the functionality of sending transactions to sign them by using private key of the corresponding account and sending them through sendRawTransaction functionality. Encrypted key for the bridge authority account must stored in a separate file. This approach requires to use network id of the corresponding blockchain and NOnce (number of operation) of the corresponding account.
4. Introduce new parameters _home_networkid, _home_accountnonce, _foreign_networkid and _home_accountnonce in the database in order to get rid of requests to the IPC/RPC nodes to track network id and NOnce required to sign transactions. A new paramter authority_keystore must keep a path to the keystore file with the private key of the bridge authority. This parameter should not belong any node in in the configuration file.

[yrashk]

One of the challenges of RPC will be the subscriptions. While not impossible, of course (there's polling), they will be somewhat saturating as we'll need to poll frequently. Considering that it most likely will have to go over HTTPS, there's also going to be a sligh cryptography-related penalty here as well. Need to check if keep-alive penalty can be avoided. There's another option to use websockets, but that might be not the best answer operations-wise. Again, as mentioned in the original issue, the delays might not be a big of an issue. But I thought it would be worth mentioning some downsides of using RPC.

[rstormsf]

@yrashk what about websockets?

[akolotov]

addressed by @yrashk in #41 and #46