[fuzz] Add a meta-differential fuzz target (#4515)

* [fuzz] Add `Module` enum, refactor `ModuleConfig`

This change adds a way to create either a single-instruction module or a
regular (big) `wasm-smith` module. It has some slight refactorings in
preparation for the use of this new code.

* [fuzz] Add `DiffValue` for differential evaluation

In order to evaluate functions with randomly-generated values, we needed
a common way to generate these values. Using the Wasmtime `Val` type is
not great because we would like to be able to implement various traits
on the new value type, e.g., to convert `Into` and `From` boxed values
of other engines we differentially fuzz against. This new type,
`DiffValue`, gives us a common ground for all the conversions and
comparisons between the other engine types.

* [fuzz] Add interface for differential engines

In order to randomly choose an engine to fuzz against, we expect all of
the engines to meet a common interface. The traits in this commit allow
us to instantiate a module from its binary form, evaluate exported
functions, and (possibly) hash the exported items of the instance.

This change has some missing pieces, though:
 - the `wasm-spec-interpreter` needs some work to be able to create
   instances, evaluate a function by name, and expose exported items
 - the `v8` engine is not implemented yet due to the complexity of its
   Rust lifetimes

* [fuzz] Use `ModuleFeatures` instead of existing configuration

When attempting to use both wasm-smith and single-instruction modules,
there is a mismatch in how we communicate what an engine must be able to
support. In the first case, we could use the `ModuleConfig`, a wrapper
for wasm-smith's `SwarmConfig`, but single-instruction modules do not
have a `SwarmConfig`--the many options simply don't apply. Here, we
instead add `ModuleFeatures` and adapt a `ModuleConfig` to that.
`ModuleFeatures` then becomes the way to communicate what features an
engine must support to evaluate functions in a module.

* [fuzz] Add a new fuzz target using the meta-differential oracle

This change adds the `differential_meta` target to the list of fuzz
targets. I expect that sometime soon this could replace the other
`differential*` targets, as it almost checks all the things those check.
The major missing piece is that currently it only chooses
single-instruction modules instead of also generating arbitrary modules
using `wasm-smith`.

Also, this change adds the concept of an ignorable error: some
differential engines will choke with certain inputs (e.g., `wasmi` might
have an old opcode mapping) which we do not want to flag as fuzz bugs.
Here we wrap those errors in `DiffIgnoreError` and then use a new helper
trait, `DiffIgnorable`, to downcast and inspect the `anyhow` error to
only panic on non-ignorable errors; the ignorable errors are converted
to one of the `arbitrary::Error` variants, which we already ignore.

* [fuzz] Compare `DiffValue` NaNs more leniently

Because arithmetic NaNs can contain arbitrary payload bits, checking
that two differential executions should produce the same result should
relax the comparison of the `F32` and `F64` types (and eventually `V128`
as well... TODO). This change adds several considerations, however, so
that in the future we make the comparison a bit stricter, e.g., re:
canonical NaNs. This change, however, just matches the current logic
used by other fuzz targets.

* review: allow hashing mutate the instance state

@alexcrichton requested that the interface be adapted to accommodate
Wasmtime's API, in which even reading from an instance could trigger
mutation of the store.

* review: refactor where configurations are made compatible

See @alexcrichton's
[suggestion](https://github.com/bytecodealliance/wasmtime/pull/4515#discussion_r928974376).

* review: convert `DiffValueType` using `TryFrom`

See @alexcrichton's
[comment](https://github.com/bytecodealliance/wasmtime/pull/4515#discussion_r928962394).

* review: adapt target implementation to Wasmtime-specific RHS

This change is joint work with @alexcrichton to adapt the structure of
the fuzz target to his comments
[here](https://github.com/bytecodealliance/wasmtime/pull/4515#pullrequestreview-1073247791).

This change:
- removes `ModuleFeatures` and the `Module` enum (for big and small
  modules)
- upgrades `SingleInstModule` to filter out cases that are not valid for
  a given `ModuleConfig`
- adds `DiffEngine::name()`
- constructs each `DiffEngine` using a `ModuleConfig`, eliminating
  `DiffIgnoreError` completely
- prints an execution rate to the `differential_meta` target

Still TODO:
- `get_exported_function_signatures` could be re-written in terms of the
  Wasmtime API instead `wasmparser`
- the fuzzer crashes eventually, we think due to the signal handler
  interference between OCaml and Wasmtime
- the spec interpreter has several cases that we skip for now but could
  be fuzzed with further work

Co-authored-by: Alex Crichton <alex@alexcrichton.com>

* fix: avoid SIGSEGV by explicitly initializing OCaml runtime first

* review: use Wasmtime's API to retrieve exported functions

Co-authored-by: Alex Crichton <alex@alexcrichton.com>

crates/fuzzing/src/generators/module.rs

@@ -0,0 +1,61 @@
+//! Generate a Wasm module and the configuration for generating it.
+
+use arbitrary::{Arbitrary, Unstructured};
+use wasm_smith::SwarmConfig;
+
+/// Default module-level configuration for fuzzing Wasmtime.
+///
+/// Internally this uses `wasm-smith`'s own `SwarmConfig` but we further refine
+/// the defaults here as well.
+#[derive(Debug, Clone)]
+pub struct ModuleConfig {
+    #[allow(missing_docs)]
+    pub config: SwarmConfig,
+}
+
+impl<'a> Arbitrary<'a> for ModuleConfig {
+    fn arbitrary(u: &mut Unstructured<'a>) -> arbitrary::Result<ModuleConfig> {
+        let mut config = SwarmConfig::arbitrary(u)?;
+
+        // Allow multi-memory by default.
+        config.max_memories = config.max_memories.max(2);
+
+        // Allow multi-table by default.
+        config.max_tables = config.max_tables.max(4);
+
+        // Allow enabling some various wasm proposals by default. Note that
+        // these are all unconditionally turned off even with
+        // `SwarmConfig::arbitrary`.
+        config.memory64_enabled = u.arbitrary()?;
+
+        // Allow the threads proposal if memory64 is not already enabled. FIXME:
+        // to allow threads and memory64 to coexist, see
+        // https://github.com/bytecodealliance/wasmtime/issues/4267.
+        config.threads_enabled = !config.memory64_enabled && u.arbitrary()?;
+
+        Ok(ModuleConfig { config })
+    }
+}
+
+impl ModuleConfig {
+    /// Uses this configuration and the supplied source of data to generate a
+    /// Wasm module.
+    ///
+    /// If a `default_fuel` is provided, the resulting module will be configured
+    /// to ensure termination; as doing so will add an additional global to the
+    /// module, the pooling allocator, if configured, must also have its globals
+    /// limit updated.
+    pub fn generate(
+        &self,
+        input: &mut Unstructured<'_>,
+        default_fuel: Option<u32>,
+    ) -> arbitrary::Result<wasm_smith::Module> {
+        let mut module = wasm_smith::Module::new(self.config.clone(), input)?;
+
+        if let Some(default_fuel) = default_fuel {
+            module.ensure_termination(default_fuel);
+        }
+
+        Ok(module)
+    }
+}