Design and implement the flow for `Message`s in the genesis block

[xgreenx]

The genesis block can be filled with Messages, but because there is no signer and no known consensus algorithm, it is unclear how to prove and bridge messages back to the settlement layer.

This issue is partially related to the fork upgrade strategy of the Fuel chain. We need to design the flow of upgradability and data transfer from the old network to a new one or remove the initial state from the ChainConfig.

[Voxelot]

Yeah the main issue at hand is that we currently need to post the entire block header to Ethereum to prove the message really exists and was signed by consensus. We might need to update the bridging protocol to have a separate withdrawal function for genesis blocks/messages, where it authenticates the message root against the genesis message root configured on the contract.

[xgreenx]

During the work on https://github.com/FuelLabs/fuel-core/pull/1625 Messages became part of the on-chain database, and the block importer has exclusive write ownership in the Messages table.

This means that messages became part of the blockchain state when we increased the DA block height and unrevertalbe unless the block was created incorrectly(it is provable via fraud proofs mechanism).

Because messages are part of the blockchain state they also should migrate to the forked network. The https://github.com/FuelLabs/fuel-core/pull/1693 performs the migration of coins, messages, and contracts. So the issue for L1 -> L2 messages migration is solved.

Regarding the L2 -> L1 case: The L2 block already contains all the required information to withdraw the money on L1. For the different versions of the block header, the L1 contract will support different API methods. Transactions and receipts are versionable by default because they are enums, so if something changes for the SMO opcode, it will be reflected in a new enum variant. The proof generation to withdraw tokens from L2 uses off-chain data (receipts and transactions), so after migration of the off-chain database, we will also support L2 -> L1 messages migration.

I'm closing this issue since there are sub-issues that resolve L2 -> L1 messages migration.