[contracts] Remove stack height limiter wasm instrumentation

[agryaznov]

We don't really need a stack limiter, because:

• we use a runtime-resident execution engine,
  hence there is no indeterminism chance caused by different stack heights, which was the case with client-sided engines;
• it's on the execution engine duty to deal with possible stack overflows,
  in our case it is handled in wasmi;
• this instrumentation itself is about of quadratic time complexity from the number of function calls the input module contains,
  hence getting rid of it we're saving the runtime resources (and therefore upload_code will take less weight);
• bonus: this also makes the resulting instrumented wasm blob lighter, therefore eating less storage and requiring less storage deposit from the contract deploy-er, let alone performance improvements to the contract execution.

[agryaznov]

/cmd queue -c bench-bot $ pallet dev pallet_contracts

[command-bot]

@agryaznov https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2168849 was started for your command "$PIPELINE_SCRIPTS_DIR/bench-bot.sh" pallet dev pallet_contracts. Check out https://gitlab.parity.io/parity/mirrors/substrate/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment /cmd cancel 115-4e56fe3a-e1ba-408d-b26c-0001895cf315 to cancel this command or /cmd cancel to cancel all commands in this pull request.

[command-bot]

@agryaznov Command "$PIPELINE_SCRIPTS_DIR/bench-bot.sh" pallet dev pallet_contracts has finished. Result: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2168849 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2168849/artifacts/download.

[melekes]

👍 (code-wise; don't know enough to reason about business logic)

[athei]

I resolved the merge conflict by choosing the upstream weight file. This didn't change the weight because the stack height limiter was already disabled (set to 0). This PR merely removed the inactive code.

[athei]

bot merge

[bkchr]

• we use a runtime-resident execution engine,
  hence there is no indeterminism chance caused by different stack heights, which was the case with client-sided engines;

Is this correct? AFAIK we don't have any deterministic stack metering for runtimes, which should result in having indeterminism for this here as well?

[athei]

We do:

substrate/client/executor/wasmtime/src/runtime.rs

Lines 702 to 704 in 9443052

	if let Some(DeterministicStackLimit { logical_max, .. }) = semantics.deterministic_stack_limit {
	blob = blob.inject_stack_depth_metering(logical_max)?;
	}

[bkchr]

substrate/client/executor/src/wasm_runtime.rs

Line 325 in 9443052

deterministic_stack_limit: None,

We don't use this for the runtimes right now :P

And there is also this issue which we probably need to fix before: #9298