Add chain parameters for the Ethereum bridge

[james-chf]

Relates to #365 and #562

This PR adds preliminary chain parameters for the Ethereum bridge, and also renames ledger runtime configuration to be under [ledger.ethereum_bridge] rather than just [ledger.ethereum]. We can change/add extra validation for these configuration parameters in other PRs.

In a network config file, Ethereum bridge parameters will be able to be specified like so:

[ethereum_bridge_params]
min_confirmations = 100

[ethereum_bridge_params.contracts]
native_erc20 = "0x1721b337BBdd2b11f9Eef736d9192a8E9Cba5872"

[ethereum_bridge_params.contracts.bridge]
address = "0x237d915037A1ba79365E84e2b8574301B6D25Ea0"
version = 1

[ethereum_bridge_params.contracts.governance]
address = "0x308728EEa73538d0edEfd95EF148Eb678F71c71D"
version = 1

These parameters as a whole are optional but if any are set, then all must be set. i.e. a Namada chain can either start without any Ethereum bridge parameters set, or with all Ethereum bridge parameters set.

This PR only adds the parameter fields, but they aren't used yet by the oracle. When validator nodes start up, they will need to check blockchain storage for the appropriate parameter values for whatever epoch they have synced to, and configure their events oracle accordingly. If no Ethereum bridge parameters have been set for a chain yet, then validator nodes don't need to start any Ethereum bridge componentry (i.e. the events oracle or geth).

Specs need to be updated for no more proxy contract (have added an item to #448)

I've tested this manually and have been able to namadac utils init-network etc. with this network config file which has Ethereum bridge parameters: network-config.toml.txt

[batconjurer]

Suggested change

	pub struct Config {
	pub struct GenesisConfig {

[batconjurer]

Confused me at first because I though this was something that could be configured when starting a node. Reading the later code, I realized that wasn't true.

[james-chf]

Have renamed to GenesisConfig

[batconjurer]

Amazes me that this type does not implement Default.

[batconjurer]

Oh wait, you do have this as a config. We can't configure minimum confirmations or addresses in a normal config. They have to be set at genesis and changed only with governance votes.

[sug0]

ah okay that makes sense, since you can run into consensus failures if two validators have different ideas of what the min number of blocks should be for an event to be considered as valid.

[james-chf]

With the Tendermint v0.37 design, we shouldn't get consensus failures if validators have different ideas of min confirmations. For the addresses of the contracts, those should change only via hard fork as far as I understand it, if we do a contract upgrade, though technically it would be possible for a a governance proposal to change them (right now as the code currently is).