Re-genesis feature

[xgreenx]

Our primary strategy to support the upgradability of the network is to create a fork of the network. A new forked network should contain all previous states from the old network in the genesis block. The name for the whole process is "Regenesis".

Adding new features/opcodes, changing how mempool works, block production, p2p communication, block synchronization, and API changes don't require a regenesis. We want to do regenesis in several cases:

• Discovering critical vulnerabilities/exploits leading to incorrect smart contract work or allowing hack contracts.
• The state transition was incorrect due to some bug in the codebase, and we need to revert the state of the blockchain.
• The private key of the block producer was compromised, and a bad actor controls the network.
• The breaking change on the VM, charging model, database side, data structure, and transaction layout.
• Change the consensus algorithm and support a new feature like the DA layer.

The transition should be smooth and unnoticeable for the users and developers:

• All previous contracts should contain the same state and balances.
• All unspent messages should remain, and API should produce valid proofs for withdrawing that work with the forked version.
• Regenesis should prevent double-spent attacks where users withdraw data/tokens from an old and new network.
• We need to figure out the transition strategy for the application that requires the whole history of events/receipts/transactions(fuel-indexer) from old and new networks.
• We must decide what to do with VM-breaking changes and contracts that cannot execute in a forked version.

The list of related issues to achieve the goals above:

• Rework the handling of the ChainConfig.initial_state during re-genesis #1209
• Design and implement the flow for Messages in the genesis block #816
• Support re-index of eth events if contract address changes #696
• Think about blocks/transactions from the previous chain.
• Re-genesis upgrade integration testing(advanced) #950
• Optional: State Rewind #451

[xgreenx]

The main functionality is done in #1693.

The remaining sub-issues are already tracked as independent epics.