The `state_root` calculation for the `Create` transaction takes an eternity

[xgreenx]

If the user provided a vast number of storage slots(in the Create transaction) during the contract creation, it takes a lot of time to calculate the state_root.

We currently use a default value 255 for the ConsensusParameters::max_storage_slots, so it is not critical. But if we want to support duplication of the contract with their state, we need to speed up this process and increase the default max_storage_slots.

[freesig]

• [ ] Benchmark and flamegraph fuel-core with "large" state
• [ ] Benchmark and flamegraph fuel-merkle with "large" state
• [ ] Compare difference

[bvrooman]

Our current approach is based on the idea that we can implement a new algorithm that takes advantage of having all the leaves of the Sparse Merkle tree up front. Theoretically, this knowledge can be used to reduce or eliminate redundant calculations when compared to sequentially updating the SMT for each leaf, where we recalculate the root at each update operation.

This means:

• Implementing a new algorithm that uses all leaves at once, rather than sequentially (this algorithm can be in the form of a new constructor or a new multi-KV update function)
• Proving the implementation is sound and correct, and produces the same roots when compared to sequential updates
• Establishing a baseline by benchmarking the performance of sequential updates
• Benchmarking the new algorithm and demonstrating that this new algorithm has superior performance (most importantly with large inputs) over the baseline