feat(sandbox): Implement LRU cache for Wasmer modules

[ukint-vs]

type CachedModule = (Vec<u8>, Arc<Module>);

static CACHED_MODULES: OnceLock<Mutex<LRUCache<CachedModule, 1024>>> =
    OnceLock::new();

In-memory cache reduces wasmer module access latency by up to 50%.
It also has a small memory footprint (I will do more testing on the testnet) that can be moved to the swap if something goes wrong.
We don't need to rely on the filesystem, now a new temporary directory is created every time, so there is no point in serializing modules to the filesystem, temp сache lifetime is the same as that of the node.
I would remove file caching if in-memory approach doesn't cause any problems.

• LRU cache with 1024 cap.
• BLAKE3 Hash only on cache miss (to store to temp file cache).

module <- LRU <- file cache <- compile

benches:

# instantiate_module_per_kb
./gear-master benchmark pallet --chain=vara-dev --steps=20 --repeat=10 --heap-pages=4096 --pallet=pallet_gear --extrinsic="instantiate_module_per_kb"
Model:
Time ~=    55.35
    + c    1.297
              µs

./gear-master-lru-hash benchmark pallet --chain=vara-dev --steps=20 --repeat=10 --heap-pages=4096 --pallet=pallet_gear --extrinsic="instantiate_module_per_kb"
Model:
Time ~=    33.42
    + c     0.76
              µs

# avoid BLAKE3 hash on cache hit
./gear-master-lru-wasm benchmark pallet --chain=vara-dev --steps=20 --repeat=10 --heap-pages=4096 --pallet=pallet_gear --extrinsic="instantiate_module_per_kb"
Model:
Time ~=    29.95
    + c    0.111
              µs

@gear-tech/dev

[NikVolf]

Consider bump host functions versions that use this, just in case? @grishasobol ?

[ukint-vs]

Consider bump host functions versions that use this, just in case? @grishasobol ?

This actually acts as a drop-in host replacement. Additionally, the current implementation does not affect the file cache in any way, since the file cache is empty every time the node is started. but I left the interaction if during further tests I have to clear the cache in memory

[grishasobol]

Consider bump host functions versions that use this, just in case? @grishasobol ?

Ok, we can consider, but actually I cannot see reasons to do this. Everything must work fine even for old blocks

[NikVolf]

Consider bump host functions versions that use this, just in case? @grishasobol ?

Ok, we can consider, but actually I cannot see reasons to do this. Everything must work fine even for old blocks

Okk, maybe test resyncing from scratch then @ukint-vs

[ukint-vs]

Consider bump host functions versions that use this, just in case? @grishasobol ?

Ok, we can consider, but actually I cannot see reasons to do this. Everything must work fine even for old blocks

Okk, maybe test resyncing from scratch then @ukint-vs

Testnet from start is ok. Without any problems

[breathx]

I'd consider using mapping within LRU caching to avoid 1024 slices comparison, e.g. use 64 bytes from the middle as keys.

Mostly, not a big deal cause wasms are differ in size and comparison goes super fast

[ukint-vs]

I'd consider using mapping within LRU caching to avoid 1024 slices comparison, e.g. use 64 bytes from the middle as keys.

Mostly, not a big deal cause wasms are differ in size and comparison goes super fast

We can't guarantee that the bytes will be unique. Yeah it's not a big deal and it's better to avoid vec manipulation which can lead to unnecessary logic. I think we can pass code_id in the future.

[grishasobol]

Looks good, just some comments to consider