Make it possible to skip storage's lazy behavior and caching

[cmichi]

We need to look into minimizing complexity in ink!. This is needed for paritytech/substrate#9354.

Problem Statement

We found that when compared to Solang-compiled contracts, ink! contracts are about three times larger (ink! ERC-20: 30K, Solang: 9K when manually run through wam-opt). The most likely explanation is that in Solang/Solidity there is no layer between runtime access calls ‒ so no lazy-datastructures and no caching ‒ reads/writes/runtime calls are just executed.
In ink! on the other hand, we have a significant complexity layer to minimize calls into the runtime. This was done with the intention of minimizing gas costs and increase performance.

A major correlation we found though is that smaller code size means better performance. This is due to the fact that runtime calls are not as performance-expensive as we thought, more Wasm bytecode is actually the performance-expensive thing.
Part of the explanation for this is that the contracts pallet injects gas metering into the Wasm bytecode. If there is more Wasm bytecode, more gas metering is injected. This gas metering is a call into the runtime. So by trying to reduce runtime calls through a complexity layer in ink! we introduced more code, which in turn unfortunately results in a gas metering runtime call.

What we should do

We have to modify ink! in a way that it's possible to skip caching and lazy mechanisms. Ideally this would happen by duplicating our ink_storage crate and modify it this way. I'm not sure if we can keep the changes local to that crate though. But if we manage, it would enable developers deciding by themselves which crate to use; this might make sense since it's likely that at least gas costs will be higher when skipping caching and lazy mechanisms.

Open Question

An open question is how gas costs of the contracts will change if we skip our cache/lazy layers. But right now the higher priority is to improve the throughput by reducing contract sizes.

[cmichi]

I'm closing this issue, since we now have the Mapping data structure which doesn't have any lazy behavior anymore.