Run Fuzzer on wasm32 Targeted Code

[almann]

As part of #56, there is a remaining TODO to integrate with the fuzzer. based on the README for rust-fuzz x86-64 is required so we cannot run the fuzzer natively on something like wasm32-wasi.

https://github.com/rust-fuzz/cargo-fuzz/blob/63730da7f95cfb21f6f5a9b0a74532f98d3983a4/README.md?plain=1#L13-L16

In order to integrate with the fuzzer, we may want to take an approach similar to the benchmarking (shim to the WASM and use a WASM runtime to embed the functionality).

[hkratz]

The main problem is that fuzzers usually use coverage information in order to check if a generated test input takes a different path through the testcase. That does not work for JIT-compiled code. Some fuzzers use blackbox fuzzing (based on timing or CPU tracing facilities) but those are less efficient finding problematic inputs.

I am not sure if fuzzing is really necessary, maybe adding some property testing using quickcheck or proptest would be sufficient?

[almann]

Yeah, this does seem a bit more involved than it would seem worth one's time--did anyone actually do fuzzing on the ARM implementation? Mostly curious to see how platform limited our tooling options are.

To your point, some property based testing might be a suitable substitution here and applicable for platforms where we don't have sufficient support for rust-fuzz and its dependencies.

[hkratz]

I did some hours of fuzz testing on aarch64 with a Raspberry Pi 4 and (I think) on my Macbook Air M1. cargo fuzz works fine at least on Linux aarch64.