Make it easier to reuse fuzzing configuration on the CLI (#10123)

* Make it easier to reuse fuzzing configuration on the CLI

During fuzzing we emit a debug log of configured options to assist with

Make it easier to reuse fuzzing configuration on the CLI (#10123)

* Make it easier to reuse fuzzing configuration on the CLI

During fuzzing we emit a debug log of configured options to assist with
reproducing fuzz test cases outside of the fuzzing harness. Mapping
options the fuzzer is using though to CLI flags, for example, is a bit
of an art though and not obvious. Just today we've got a fuzz bug and I
couldn't figure out how to reproduce on the CLI and it turns out the
issue was that I was forgetting a flag that was being configured in
response to another flag. I got a bit fed up with constantly trying to
map one to the other, so I've decided to fix things.

This commit adds a `Display for CommonOptions` implementation to the
`wasmtime-cli-flags` crate. This is built on the same macro-construction
infrastructure of all our flags making it a relatively low one-time-cost
to implement this. Each option value now implements not only parsing but
printing as well.

Next the `wasmtime-fuzzing` crate was updated to create a
`CommonOptions` first which is then in turn used to create a
`wasmtime::Config`. This provides a layer to insert a log statement with
to emit all configuration options in a form that can be easily
copy/pasted to the CLI to reproduce.

Overall after doing this I was able to quickly reproduce the bug in
question (yay!). The CLI flag logging is pretty verbose right now since
the fuzzing infrastructure sets many settings redundantly to their
defaults, but reducing flags to a minimum is expected to be relatively
easy compared to otherwise trying to extract the options.

* Fix build and dependencies from wasmtime-fuzzing

* Always provide `wasmtime::MpkEnabled`

It's an otherwise very small `enum` which makes it easier to
conditionally compile `wasmtime-cli-flags`

* Frob some crate features some more

* Fix specification of `wasmtime_linkopt_force_jump_veneer` option

show more ...

Refactor configuration for the pooling allocator (#5205)

This commit changes the APIs in the `wasmtime` crate for configuring the
pooling allocator. I plan on adding a few more configuration option

Refactor configuration for the pooling allocator (#5205)

This commit changes the APIs in the `wasmtime` crate for configuring the
pooling allocator. I plan on adding a few more configuration options in
the near future and the current structure was feeling unwieldy for
adding these new abstractions.

The previous `struct`-based API has been replaced with a builder-style
API in a similar shape as to `Config`. This is done to help make it
easier to add more configuration options in the future through adding
more methods as opposed to adding more field which could break prior
initializations.

show more ...

fuzz: refactor fuzz generators (#4404)

Previously, much of the logic for generating the various objects needed
for fuzzing was concentrated primarily in `generators.rs`. In trying to
piece togethe

fuzz: refactor fuzz generators (#4404)

Previously, much of the logic for generating the various objects needed
for fuzzing was concentrated primarily in `generators.rs`. In trying to
piece together what code does what, the size of the file and the light
documentation make it hard to discern what each part does. Since several
generator structures had been split out as separate modules in the
`generators/` directory, this change takes that refactoring further by
moving the structures in `generators.rs` to their own modules. No logic
changes were made, only the addition of documentation in a few places.

show more ...