[Kranzes]

NEEDS #270. This branch is stacked on #270, which is stacked on #267. The commits of this PR start at "benchmark: measure vectored IO and the passthrough thread pool".

On the tokio runtime, every async file operation is a blocking preadv() or pwritev() on the runtime thread. That runtime serves macOS, Linux without io_uring, and applications that drive FuseDevTask from their own tokio runtime (#267). This makes those calls fewer, and moves the ones that block onto the blocking thread pool when PassthroughFs::enable_async_thread_pool(true) is set.

• benchmark: measure vectored IO and the passthrough thread pool. async_io_microbench times vectored writes and reads of 1, 16 and 256 page-sized buffers, and PassthroughFs READ and WRITE with the pool off and on. The daemon gets --thread-pool, and bench_sync_async.sh gets a pool mode.
• async-io: read and write vectored buffers with one syscall on tokio. The vectored file methods split the buffers into one operation each, which adds no concurrency on tokio. A virtio-fs WRITE of 1 MiB in 256 pages made 256 pwritev() calls. They now make one call per 1024 buffers. io_uring keeps the split. The new RuntimeType::file_io_blocks() tells callers whether file IO blocks the calling thread.
• passthrough: serve blocking READ and WRITE on the thread pool. With the pool enabled, READ cache misses and WRITEs on tokio, and the O_DIRECT and WRITE_KILL_PRIV requests on any runtime, run the sync handlers on a pool thread. The pool thread works on its own copy of the data and never touches the transport buffer. A task that hasn't started when its request is dropped, for example for a takeover, doesn't run.
• passthrough: don't make LSEEK wait for READ and WRITE. lseek() takes the handle's read lock instead of its write lock, so an LSEEK no longer waits for a pooled READ or WRITE on the same handle. It also drops the handle's cached readdir cookie, which a seek makes stale.
• passthrough: look up the handle once for a pooled READ. A READ that misses the page cache passes the handle data it looked up for the inline attempt to the pool. In no_open mode that saves one open() per READ.
• passthrough: copy O_DIRECT data once on the thread pool. The pool's buffer starts at a page boundary, so a pooled O_DIRECT READ or WRITE does its IO on it directly, without the sync handler's bounce buffer. Its allocation also fails with ENOMEM where the WRITE payload's Vec used to abort.
• passthrough: undo pooled LOOKUP, OPEN and CREATE that nobody receives. If a request is dropped while a pool thread serves its LOOKUP, OPEN or CREATE, the handle or lookup count it creates never reaches the kernel. The pool task now returns its result in a guard that releases the handle or forgets the lookup if nobody claims it.

Measured on an AMD Ryzen AI 9 HX 370 with Linux 7.2.7, one worker on tokio, backing files on ext4:

	before	after
256 × 4 KiB vectored write (cached)	144 µs	22.5 µs
256 × 4 KiB vectored read (cached)	67 µs	20 µs
reading a file while another READ waits in a slow FUSE file system below, pool on	2 s	1.6 ms
fio random 4 KiB reads, 4 jobs, cold cache, pool on	12.1K IOPS	34.5K IOPS
fio random 4 KiB writes, cached, pool on	433K IOPS	424K IOPS

The pool costs one copy and a thread handoff per request, about 3.5 µs for 4 KiB. A pooled 4 KiB O_DIRECT READ takes 23.4 µs instead of 24.7 µs with two copies, and a pooled buffered 1 MiB READ 37.8 µs instead of 43.2 µs.

Known limitations, which I left for later:

• READ cache hits stay inline only on file systems with RWF_NOWAIT. On tmpfs, overlayfs and FUSE every READ goes to the pool.
• A pool task that already runs when its request is dropped completes. The kernel may send the request again after a takeover, so a WRITE to an O_APPEND file can land twice, and an O_EXCL CREATE fails with EEXIST because the first one's file stays. Stopping the serving task through its state flag avoids that, and the docs say so.
• A READ or WRITE that flips the handle's O_DIRECT flag holds the write lock for its whole IO, so an LSEEK on that handle still waits for it.