Not actively working on this yet, but recording some thoughts for later...

The tricky part of this will be in the disk image file format implementations.

I'm not sure it's worth the trouble to try this for qcow2, since a lot of its operations currently depend on being single-threaded for safety (allocating new clusters, updating L1/L2 tables and refcounts, etc.).  We could try to add locking around the critical sections, but the plan going forward is to use raw images for performance anyway. We'll still need to allow qcow images, but they can probably be limited to synchronous I/O (or only one worker thread).

For raw images, it should be much more tractable, but we need to figure out what asynchronous I/O strategy to use.  A few options:
- Thread pool with each worker executing normal blocking I/O (probably the simplest; just need to distribute requests to workers somehow).
- Linux AIO (libaio) via a Rust wrapper (note that there is currently no asynchronous fsync(), and io_submit() may block on some operations like allocating blocks in the underlying filesystem, so this isn't fully asynchronous; also, we'd need to switch to opening the image with O_DIRECT, bypassing the page cache).
- Some existing asynchronous I/O framework like tokio (this seems to be mostly focused on network sockets; I'm not sure what it does for local file I/O).