Update and evaluate wasmi

[mariaschett]

With the wasmi update we should revisit whether our original assumptions and reasons for choosing wasmi still hold.

Our reasons for wasmi:

• no JIT compilation, hence requires no executable memory
• we do not need wasi
• we need no_std

[tiziano88]

• no JIT compilation, hence requires no executable memory

More precisely, it requires no memory that is both writable and executable. It is fine (in fact, necessary) to have executable memory.

Also to add to the list of requirements is that it must work on a single threaded environment and without async.

[tiziano88]

For the record, I believe you were suggesting looking at https://github.com/bytecodealliance/wasmtime , right?

[mariaschett]

As wasmi does not support calling Wasm functions from host functions after the update (cf. github.com/paritytech/wasmi/issues/572), our current implementation of alloc deadlocks.

[mariaschett]

Options to mitigate:

1. wait until wasmi updates: preferred option, and seems likely
2. implement alloc differently with multiple calls between host and module: One idea is to guess an initial buffer size and try, on fail increase buffer size and try again. Another idea is to have multipe calls instead of alloc: Call 1: module asks host for the size of the request. Call 2: module allocs k and sends pointer to host, where host writes the request. This would probably work for read_request but will be problematic with invoke, where the host needs to write the response. Finally, there is the idea based on channels: invoke returns a handle, and then separately the module can attempt to read from that handle by asking how large the contained message is in order to allocate the exact amount of memory.
3. look for a different no_std/no JIT Wasm interpreter: this seems unlikely.