Change child predicates deployment

[goran-ethernal]

Description

This PR changes the way how child predicates are deployed.

Now all bridge contracts deployed on blade are removed from the genesis command. Instead, they are deployed in the bridge deploy command.

Bridge deploy logic

Since bridge deploy command is the one that deploys everything the bridge needs, it was a logical place to add deployment of bridge contracts on blade as well, separating the genesis from bridge completely.

Since blade can have connection to multiple external chains, meaning, a single blade chain can have multiple bridges in relation 1 to 1 (1 bridge to 1 chain), each bridge needs to have its bridge contract pairs on both chains (external and blade).
This means that for example, if blade has 2 bridges, one to Ethereum, one to Polygon, bridge contracts will be deployed on those two external chains, and as well their corresponding counterparts on blade, so we have two Gateway contracts on blade one for Ethereum, one for Polygon.

Genesis command

Removed deployment of all bridge contracts from it.

Bridge Deploy command

Moved all the child predicates (internal bridge contracts) deployment to the command.
These are all the changes in the command:

• added two new flags:
  • bootstrap which indicates if bridge deploy command is executed on blade chain bootstrapping. By default is true.
  • internal-json-rpc which defines rpc url to the live blade chain if the command is not run on bootstrapping blade.
  • changed the name of json-rpc flag to external-json-rpc flag, which defines the rpc url to the external chain.
• separated setup of external and internal contracts to their corresponding files (internal_contracts.go and external_contracts.go).
• added logic if the command is running in bootstrap mode (meaning, blade is being setup), the child predicates (internal bridge contracts) can not be deployed in the command, rather it will only calculate their addresses and pre-allocate them in genesis.
• added logic if the command is not running in bootstrap mode (meaning, blade is already live), the child predicates must be deployed through the command (can not be pre-allocated in genesis, since we can not change genesis after the chain is live). The command will then deployed them and initialize them immediately. It will also update its bridge config as well to save the contracts addresses. This mode is used when some clients want to add new bridges from blade to some other chain and vice verse, while the blade chain is still live. Since addresses of new contracts are saved in the genesis.json file in the corresponding bridge configuration, in this case, the nodes need to be restarted.

Polybft

In the GenesisPostHook added logic to initialize child predicates (internal bridge contracts) for each configured bridge, but only if they are in the pre-allocation map that the bridge deploy command updated. If they are not in the map, then we do not need to initialize them in the GenesisPostHook, since the command already did that.

System Addresses

Reorganized system (fixed) addresses, since their values were scattered from range to range. Also removed unnecessary ones.

Bridge Config

Now contains addresses of both external and internal (blade) bridge contracts.

Changes include

• Bugfix (non-breaking change that solves an issue)
• Hotfix (change that solves an urgent issue, and requires immediate attention)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)

Checklist

• I have assigned this PR to myself
• I have added at least 1 reviewer
• I have added the relevant labels
• I have updated the official documentation
• I have added sufficient documentation in code

Testing

• I have tested this code with the official test suite
• I have tested this code manually

[dusannosovic-ethernal]

LGTM

[Stefan-Ethernal]

LGTM, but have a couple of questions