Store the blocks which include deployment/upgrade transactions in the contracts

[akolotov]

Currently the block number which includes deployment transaction stored in the database file. This number could be used in recovery scenarios to try reapplying all skipped transactions: go through all the blocks since the block the contract was created and filter deploy/withdraw events. It is also useful to deploy several new bridge instances: every bridge will start filtering events starting from the same block.

In order to simplify deployment of new bridges it could be worth to store this information in the bridge contract instead of storing it in database file: bridge deployment process could get this information from the contracts in order to generate database file with correct checked_deposit_relay, checked_withdraw_relay and checked_withdraw_confirm. So, it will be no necessity to distribute the database file among the target systems.

Proposals for changes

Solidity

1. Introduce deployedAtBlock public field in HomeBridge and ForeignBridge contracts.
2. This field initialized within the contract creation process with the block number.

Rust

1. Change the logic of generating database file as so if there are no checked_deposit_relay, checked_withdraw_relay and checked_withdraw_confirm defined in the file, deployedAtBlock is read from the corresponding contract and the parameters are initialized in the values received from the contract.
2. Remove the code which write home_deploy and foreign_deploy to the database file.

[rstormsf]

Just to clarify: Rust side needs to read deployedAtBlock public field and start processing relays at that value

[rstormsf]

Solidity side is done

[yrashk]

Please let me know if we still need this and I'll implement it if we do.

[akolotov]

Yes, the bridge should extract block number to start watching for events from from contracts by using deployedAtBlock(). In this case the database to start the bridge instance with at the very first time will contain only contract addresses.