feat: io_uring-based file I/O for search hot path

Is your feature request related to a problem? Please describe.

Quickwit's file I/O goes through Tokio's blocking thread pool because epoll does not support file descriptors. Under high query concurrency, each posting list fetch is a blocking read() dispatched to a thread, adding scheduling overhead and capping throughput. At sustained high QPS this becomes the dominant bottleneck.

Describe the solution you'd like

Use io_uring for file I/O in the search hot path. io_uring eliminates the syscall round-trip via a shared ring buffer between userspace and the kernel. For random-read workloads on NVMe (posting lists, doc store segments) benchmarks consistently show 40-60% latency reduction and 2x+ throughput at high concurrency.

Two implementation paths:

• compio -- async runtime built on io_uring, composable with existing futures. Requires replacing Tokio file I/O in the search path.
• tokio-uring -- narrower scope, drop-in for Tokio's file ops.

Minimum kernel requirement: Linux 5.19. Can fall back to standard I/O on older kernels or non-Linux platforms.

Describe alternatives you've considered

Increasing the Tokio blocking thread pool size reduces contention but does not eliminate the syscall overhead or the context-switch cost per I/O operation.

Additional context

Apache Iggy (https://github.com/apache/iggy) runs its entire I/O stack on io_uring via compio (thread-per-core, shared-nothing). Their production experience serves as a reference implementation for this approach in a Rust async codebase.

Start by tracing Quickwit's search hot path and the Tokio blocking-thread-pool file reads used for posting lists and doc store segments. Compare the compio and tokio-uring approaches described in the issue, then define how older Linux kernels and non-Linux platforms fall back to standard I/O. Done requires an agreed implementation path and throughput and latency measurements under high concurrency.