Reimplement fast-path validation of MVP types

[alexcrichton]

This commit fixes an issue from #1906 which is preventing the upgrade of
wasm-tools in Wasmtime. That commit implemented a fast path by skipping
a function and reimplementing parts of it internally, but that then
caused Wasmtime to panic when other data structures weren't filled out.
The intention was that the user-facing interface doesn't change
depending on features, so this is an attempt at fixing the mistake in
that commit.

The fix here is to remove the fast path added and restructure it
differently. Instead now the fast and normal paths have much less
divergence which should prevent this issue from re-surfacing. This is
15% slower than main but it doesn't have the same bug as main so for
now that may be the best that can be done.

[alexcrichton]

cc @Robbepop

[Robbepop]

@alexcrichton looks reasonable.

Can you provide me a link to the Wasmtime issue?

It is nicer that you managed to unify both implementations. The 15% slowdown is a bummer. Do you have an idea how to make it faster again? According to my benchmarks wasmparser v0.221 is still ~5-15% slower than wasmparser v0.100 for Wasmi but I deemed that an acceptable trade-off. However, I would rather want to make the newer wasmparser faster. :) I am hopeful we find more ways to do so.

[Robbepop]

LGTM

The new needs_type_canonicalization needs a #[cfg(feature = "validate")] to fix CI issues.

[alexcrichton]

No issue on the wasmtime side, just a failed build. The failure is in this loop which is iterating by rec groups and specifically this one was the failure where the fast path wasn't maintaining the rec group lists.

My guess is we could probably skip maintenance of the rec group lists entirely in the fast path, but only if the other paths that read these lists understand that they may be optional and/or not populated. That might require plumbing WasmFeatures more. I've long wanted to just store WasmFeatures on self in more places as it's currently plumbed in about a million places which is a bummer (and it's super small at 4-bytes so basically inconsequential to duplicate)

[Robbepop]

My guess is we could probably skip maintenance of the rec group lists entirely in the fast path, but only if the other paths that read these lists understand that they may be optional and/or not populated. That might require plumbing WasmFeatures more. I've long wanted to just store WasmFeatures on self in more places as it's currently plumbed in about a million places which is a bummer (and it's super small at 4-bytes so basically inconsequential to duplicate)

Sounds great and worthwhile!