LEP: Split tokio runtime and dedicated file I/O with async

[mjansson]

Summary

This proposal replaces Lore's open-ended thread model with a fixed budget known at initialization, through three structural moves.

First, the network transport (QUIC, gRPC) moves onto a small dedicated runtime — two threads on the client; up to one per processor on the server, where thousands of concurrent client connections are the normal case — so protocol timers, TLS, and packet processing are never delayed by compute or I/O continuations saturating the core workers.

Second, the separate compute thread pool is deleted: compression, hashing, and chunking are fragment-sized work units (≤256 KiB, single-digit milliseconds worst case) that run inline in tasks on the per-processor core workers, removing a full CPU-count thread population.

Third, file I/O leaves the tokio blocking pool for a dedicated I/O engine: a bounded, idle-reaped pool of positional-syscall threads (min(2 × cores, 32)) as the portable baseline — the permanent engine on macOS and the fallback wherever completion-based I/O is unavailable — upgraded to completion-based asynchronous I/O (io_uring on Linux, overlapped I/O on Windows) where the platform offers it, at which point data-plane parallelism — reads, writes, flushes — becomes operating-system queue depth instead of thread count, with the pool retained for metadata and composite operations. What remains of the core runtime's blocking pool is a residual ~4 threads serving OS APIs with no asynchronous form.

[matt-hoffman-epic]

I don't have insight into the specifics behind io_uring and Windows' overlapped I/O, so I can't really approve the specifics of those being able to support a larger number of queued operations w/o requiring more threads.
But taking your word on that, this SGTM.

[matt-hoffman-epic]

This work intersects w/ the SWFS work to put file operations in Lore operations behind the FilesystemProvider interface.
I don't think it actually affects this plan directly, that interface has higher level operations like "read a Node from the ImmutableStore into a file" rather than "write to a file". But having this phase finished might simplify auditing code in the lore-revision crate.

[matt-hoffman-epic]

Confirming I understand correctly:
This is "portable", but due to using posix calls that just means consistently available on *nix?
Windows will only have the single implementation because we know it's available?