Right now, the executors are written with atomic harnesses in mind -- the observers are prepared, then the harness is executed, then the observers are processed. This may not be optimal for e.g. network or filesystem fuzzing where resources are dynamically requested by the target, situations where we want to observe multiple parts of the harness separately (such as in differential- or property-fuzzing), or where using atomic harnesses may not be as efficient due to the allocation of shared resources (e.g. differential fuzzing PCRE2, we would want to avoid compiling the regex twice for the interpreter and the JIT). This also simplifies the job of the fuzzer developer, as they can reuse existing harnesses and only add callbacks to delineate the stages of the harness execution.

With that in mind, we should probably implement the infrastructure to easily implement harness/fuzzer interactions. This is most relevant for in-process executor, where we need to stash the fuzzer/state/executor/etc., do mutability checks, potentially pause/cancel timeouts, etc. in a way that is likely non-obvious for developers that aren't us 🙂

We can implement this as part of the executor changes originally discussed in #1341 s.t. we have a global representing the current state to be used by more than just the signal handlers.

To implement this, I suggest we extract the global used by the signal handler to a global that is more widely available, then define a HarnessCallback<E> trait, generic over executor E. Individual support for different executor variants can then be implemented by the executor developers and blanket implemented for the callbacks. The specific callback functions can then be defined by the fuzzer developer + some common ones we can implement by default.