Rework the handling of the ChainConfig.initial_state during re-genesis

[xgreenx]

We must process a huge state if we need to re-genesis in the mainnet. It can be so huge that it can not even fit into the RAM. So, we need to re-work the initial state handling.

The obvious solution is to stream the state from the file and process it with chunks. Because this process can be long, we also need to support interruption and continuing from the place where we've stopped. Also, the initial_state field in the ChainConfig should be replaced with the final result like genesis hash or genesis metadata instead of storing the whole state in the RAM.

[xgreenx]

Based on the internal conversation, we agreed that the work can be paralyzed in several ways:

1. Extract the initial_state from the ChainConfig #1450 - Extract the initial_state from the ChainConfig. We still need it during the start of the network, so this information should be provided along with ChainConfig. But it can be done as a separate file or as an optional field. It would be nice to integrate it with the loading snapshot functionality.
2. Determine file encoding for initial state #1396 - The current serde JSON format is hard to stream. It can be replaced with a custom or any already implemented format. The person who works on this part should compare existing solutions and decide which to select based on the integration complexity and performance.
3. Make pushing/loading of the state streamable.
4. The streaming itself should be pausable/resumable. It means we need to store a temporary, not finalized, database somewhere. When the snapshot loading is finished, we must make a temporary database our main database. Also, the temporary database may store some information about where we stopped. This information also should be cleaned up at the end.
5. We store all contracts and balances in the memory during the snapshot creation. We need to make it streamable to file too. We should be able to reuse the mechanism created for streamable snapshot loading above.
6. The code requires adaptation to work with streamed data. It may require the introduction of some abstraction(mostly by traits) to support streaming. Also, we may support different formats in the future, so it would be nice if this abstraction is format agnostic.
7. During the initial benchmark, it becomes clear that BMT consumes a lot of memory for huge snapshots. The solution is to create an optimized version of the BMT that doesn't store all leaves and nodes. We can store only the nodes required to build the next nodes. It should drastically reduce memory consumption. The alternative solution is to use storage to store all nodes, but it is better to do this after optimized BMT. - Done Improved Memory Efficiency in Merkle Root Calculation fuel-vm#603

[xgreenx]

Also, maybe we need to think about migration. Do we want to make it part of the regenesis, or do we want to have a separate flow to migrate it?