Switch fuzzers to use new Cranelift backend.

[cfallin]

As per bytecodealliance/rfcs#10, the first step in our transition to the
new Cranelift x86-64 backend by default in Wasmtime is to switch our
fuzzers and monitor for any breakage.

This PR moves all Wasmtime fuzz targets over to use the new backend. The
differential old-vs-new-backend target still works by dynamically
selecting both backends (the build feature just changes the default,
which is what all the other fuzz targets use).

We should watch for ~a week or so, I think, on oss-fuzz, to make sure
this sticks without issue before moving further.

[github-actions]

Subscribe to Label Action

cc @fitzgen

Details

This issue or pull request has been labeled: "fuzzing"

Thus the following users have been cc'd because of the following labels:

• fitzgen: fuzzing

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[fitzgen]

\o/

[cfallin]

Hmm, the test failure seems to indicate that the feature is leaking and turning on the new backend in other tests -- I don't claim to fully understand the new feature resolver, any thoughts @alexcrichton? Digging in further.

[bjorn3]

I don't think Wasmtime has switched to the new resolver yet. You need to add

[workspace]
resolver = "2"

to the top-level Cargo.toml to enable it.

[alexcrichton]

Given Cargo's behavior to unify features I don't think it will be easy to have a specific default per component of wasmtime in our CI like this.

I think if we want to do this we should probably do the switch here -- https://github.com/google/oss-fuzz/blob/54f0985f8ed3055e1bbfa19eb2f67623cf952162/projects/wasmtime/build.sh#L59-L63. This would have to update that anyway since the feature is going away too.

[cfallin]

Hmm, yes, that's probably the better option. I'll go ahead and create a PR over there. Thanks!