make the fuzzer to have multiple executors

[keymaker-arch]

Is your feature request related to a problem? Please describe.
I'm currently fuzzing the Linux kernel in a Syzkaller-like setup, where an executor agent (similar to syz-executor) runs inside a QEMU VM. This agent executes seeds on behalf of the LibAFL executor and communicates with it via a TCP connection. In my design, the LibAFL executor is a lightweight wrapper around the QEMU VM harness, responsible for dispatching commands and seeds to the executor agent inside the VM.

Describe the solution you'd like
I would like LibAFL to support multiple executors within a single fuzzer instance. In this setup, the fuzzer could:

1. Assign seeds to idle executors within the same fuzzer instance.
2. Asynchronously monitor all executors for completed tasks.
3. Evaluate the execution results as they are returned.

This would allow me to run multiple executor agents inside a single VM, significantly reducing the memory usage of running multiple VMs while maintaining the ability to fuzz concurrently.

Describe alternatives you've considered

• Multiple fuzzer instances: I considered running multiple fuzzer instances, each with its own VM. However, this approach is inefficient in my use case due to the high memory overhead of running multiple VMs.
• Custom executor management: I could implement custom logic outside of LibAFL to manage multiple executor agents within a single VM. However, this would require significant effort and would duplicate functionality that could be integrated into LibAFL itself.

Additional context
In my use case, the host-side LibAFL executor is a lightweight wrapper of my custom harness that communicates with the VM-side executor agent via TCP to dispatch commands and seeds. Supporting multiple executors within a single fuzzer instance would allow me to leverage this design more effectively, enabling concurrent fuzzing without the need for multiple VMs.

[addisoncrump]

I tried implementing this a while ago, see #913. There are lots of trade offs which make this an uncomfortable change, but the idea of decoupling executors and fuzzer instances is certainly appealing. You can refer to my previous work if you want to try to make this change yourself, but in the meantime, I would make an executor which calls out to your dispatcher, then have your dispatcher manage executions and feed back results as possible. You'll need a custom mutation stage to accommodate this.