fix wasm host-in-guest alloc

[tzemanovic]

Describe your changes

This fixes an issue with tx and VP WASM inputs that are larger than the initial WASM memory and hence require to grow memory. It turned out that simply calling memory.grow for this (as performed by memory::write_memory_bytes from host didn't update the guest properly which was then overriding the already used memory ranges from the initial data and hence corrupting the memory, leading to WASM runtime memory errors.

To fix this, we're now injecting and exporting a simple alloc fn into WASMs and calling it from host to write the initial data.

Additionally, the max WASM memory size is increased as with the current limit it was not possible to decode a tx with 2 MiB of data (the newly added wasm::run::tests::test_tx_alloc test would fail with unreachable when it runs out of memory).

For a tx with data that fits in the initial memory size there is no change in WASM execution (the alloc call will return early).

The Rust src for the alloc fn that's being injected is here https://github.com/namada-net/namada-wasm-min-alloc

Checklist before merging

• If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
  • This will require 2 reviewers to approve the changes
• If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
  • Relevant PR if applies:
• If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
  • Relevant PR if applies:

[sug0]

quick review of namada-wasm-min-alloc:
https://github.com/namada-net/namada-wasm-min-alloc/blob/5e654ca43c93bf74dfa5ce6628fae35e82dbb3b4/src/lib.rs#L43-L46
shouldn't the panic handler simply be wasm32::unreachable()?

[tzemanovic]

quick review of namada-wasm-min-alloc: https://github.com/namada-net/namada-wasm-min-alloc/blob/5e654ca43c93bf74dfa5ce6628fae35e82dbb3b4/src/lib.rs#L43-L46 shouldn't the panic handler simply be wasm32::unreachable()?

it doesn't matter, it doesn't affect the generated code as it's panic-free