Precise stack depth metering for PVF

[pepyakin]

Currently for PVF execution we are using a rather naive algorithm for stack metering.

See:

• https://github.com/paritytech/wasm-utils/blob/master/src/stack_height/mod.rs
• https://github.com/paritytech/substrate/blob/3cd75117765c4a63d40c00aa41e1bf12135c237b/client/executor/wasmtime/src/runtime.rs#L262-L304
• https://github.com/paritytech/substrate/blob/3cd75117765c4a63d40c00aa41e1bf12135c237b/client/executor/wasmtime/src/runtime.rs#L322-L331

However this simple model does not actually represent the underlying behavior of an optimizing compiler. Right now we try to overcome this by generously allocating the stack space for a relative small number of logical items. What I've missed is that the regalloc will generate spill slots based on the number of active live ranges.

See this discussion https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/deterministic.20stack.20usage

Introducing the additional parameters into the mix is rather annoying and provides a very rough upper bound which I am not sure if useful.

As an alternative, Chris F. has suggested to look into having a virtually unlimited native stack and throw a stack overflow trap based on logical consumption. It's not trivial to implement though. There are certain considerations, i.e. how exactly provide such a stretchable native stack. If done naively we could introduce performance cliffs (such as what segmented stacks in Go had).

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/ux-implications-of-pvf-executor-environment-versioning/2519/31