Cranelift: remove slow invariant validation in cfg(fuzzing) from Mach…

…Buffer. (bytecodealliance#4038)

Following the merge of regalloc2 support, this became slower because we
are stricter about the critical-edge invariant, generating a separate
edge block for every out-edge even if two or more out-edges go to the
same successor (this is significant in cases of `br_table` with many
entries having the same target block, for example).

Many of those edge blocks are empty and end up collapsed by the
MachBuffer, which leads to a large set of aliased labels.

The invariant validation will dutifully iterate over all the data
structures at every step, validating all of our conditions. But this
gets way slower in the new context, to the point that we'll probably
have some fuzz timeouts.

This was pointed out in [1] but I missed removing this in bytecodealliance#3989. Given
that `MachBuffer` has been around for nearly two years now, has been
fuzzed continuously with the invariant validation for that time, and
also has a correctness proof in the comments, it's probably reasonable
to remove this high (recently increased) cost from the fuzzing-specific
compilation configuration.

[1]
bytecodealliance#3989 (comment)

Release notes and version bumps for 0.35.3. (bytecodealliance#4014)

* Release notes for 0.35.3.

* Bumped all crate versions for Wasmtime 0.35.3 / Cranelift 0.82.3 patch release.

[automatically-tag-and-release-this-commit]

Release Wasmtime 0.35.2 (bytecodealliance#3985)

* Bump Wasmtime to 0.35.2

[automatically-tag-and-release-this-commit]

* Add release notes for 0.35.2

Co-authored-by: Wasmtime Publish <[email protected]>
Co-authored-by: Nick Fitzgerald <[email protected]>

Release Wasmtime 0.34.2 (bytecodealliance#3984)

* Bump Wasmtime to 0.34.2

[automatically-tag-and-release-this-commit]

* Add release notes for 0.34.2

* Disable stack overflow tests on Windows

This test is disabled on Windows because we determined it is too risky to back
port bytecodealliance#3861 to the 0.34.x
release branch.

* Switch back to windows-2019 on CI (bytecodealliance#3854)

Looks like windows-2022 is failing, let's perhaps pin for now?

Co-authored-by: Wasmtime Publish <[email protected]>
Co-authored-by: Nick Fitzgerald <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

Bump Wasmtime to 0.35.1 (bytecodealliance#3911)

[automatically-tag-and-release-this-commit]

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 0.35.0 (bytecodealliance#3885)

[automatically-tag-and-release-this-commit]

Co-authored-by: Wasmtime Publish <[email protected]>

Release Wasmtime 0.34.1 (bytecodealliance#3812)

* Bump Wasmtime to 0.34.1

[automatically-tag-and-release-this-commit]

* Update RELEASES for 0.34.1.

Co-authored-by: Wasmtime Publish <[email protected]>
Co-authored-by: Peter Huene <[email protected]>

Release Wasmtime 0.33.1 (bytecodealliance#3813)

* Bump Wasmtime to 0.33.1

[automatically-tag-and-release-this-commit]

* Update RELEASES for 0.33.1.

* Try to fix CI for Rust 1.58 (bytecodealliance#3689)

PATH lookup for WIndows command execution was tweaked slightly to not
search the cwd, so let's see if this fixes things...

Co-authored-by: Wasmtime Publish <[email protected]>
Co-authored-by: Peter Huene <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

Release Wasmtime 0.34.0 (bytecodealliance#3768)

* Bump Wasmtime to 0.34.0

[automatically-tag-and-release-this-commit]

* Add release notes for 0.34.0

* Update release date to today

Co-authored-by: Wasmtime Publish <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

Release Wasmtime 0.33.0 (bytecodealliance#3648)

* Bump Wasmtime to 0.33.0

[automatically-tag-and-release-this-commit]

* Update relnotes for 0.33.0

* Wordsmithing relnotes

Co-authored-by: Wasmtime Publish <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>