Unified fuzz-harness interface

[graydon]

Over the years we've created or contracted the creation of several different fuzz harnesses (the tx fuzzer, an overlay fuzzer, a half dozen soroban fuzzers).

These have all to varying extent suffered from neglect:

• Some don't even get committed/merged into any main repos (eg. they're just part of audit contracts)
• Some don't all get built or checked for correct function regularly
• Some (most? all?) don't get run continuously
• We're not in oss-fuzz in particular
• They're not integrated into (pseudo-)randomized unit testing very well (we use an ancient version of autocheck; it might be nice to try to expose such tests as miniature fuzz harnesses (eg. in github.com/google/fuzztest)

It would be nice to have a bit more unified infrastructure for fuzzing to address these shortcomings. Ideally we'd have:

• a single top-level entrypoint dispatching to all existing fuzz harnesses in core and soroban
• that is merged into master and built-and-run-a-bit as part of CI so it never breaks
• that is driven by the best option for fuzzer engines (probably honggfuzz)
• that is registered with oss-fuzz for continuous fuzzing on google infra
• that is easy and obvious to extend with new harnesses when we contract for them
• bonus: that is connected in some way to unit tests so they can naturally get registered as more harnesses

[MonsieurNicolas]

Thank you. This looks great.

I would suggest also:

• hooking up genfuzz in the same way, and maybe change it to generate a full corpus on its own (instead of generating a single file) that way bootstrapping does not require a loop (like we have now in the fuzz target) and each fuzzer gets to decide how many (or which) seed files to generate.
• make it that it's still possible to run a single fuzzer (could be as simple as: I imagine that internally we'll loop over some list of registered handlers, can we just optionally pass a list to the fuzz and genfuzz commands? There should be a way to list as well if we go that route)
• cleanup code to remove all "non interesting" or non-deterministic bits of the app that we should be excluding as part of fuzzing (things like: metrics subsystem should be compiled out)
• perform some sort of sanity check for stability (as it's something we're likely to break)
  * for each fuzzer, during acceptance test, check that stability is over some number when running on the (minified) corpus using something like afl-showmap -m none -t 500 -o cov.txt -- ./target XYZ
  * run a short fuzzing session (1 hour) over a nightly build, and check that stability is high