fs: add io_uring open operation

[mox692]

WIP.

This PR is based on the changes from #7320 and demonstrates how to support uring operations on top of that. This branch implements the open operation and has some tests.

The implementation in this PR may be changed depending on the updates of the base PR.

[mox692]

I ran a benchmark in commit d0dc6b2.

settings

$ uname -a
Linux mox692-ThinkPad-P51 6.8.0-59-generic 61-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 11 23:16:11 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

# On commit `d0dc6b2`,

# uring bench
$ RUSTFLAGS="--cfg tokio_unstable_uring" cargo bench open_many_files

# thread pool bench
$ cargo bench open_many_files

Single-threaded runtime

Benchmark Name	Thread Pool	Uring
open_many_files	[5.0981 µs 5.1226 µs 5.1520 µs]	[4.1279 µs 4.1374 µs 4.1479 µs]

Multi-threaded runtime

Benchmark Name	Thread Pool	Uring
open_many_files/2 threads	[3.5071 µs 3.5448 µs 3.5911 µs]	[4.0503 µs 4.1464 µs 4.2529 µs]
open_many_files/4 threads	[3.2188 µs 3.2382 µs 3.2582 µs]	[5.0549 µs 5.1624 µs 5.2627 µs]
open_many_files/8 threads	[3.2208 µs 3.2434 µs 3.2663 µs]	[6.6902 µs 6.7288 µs 6.7705 µs]
open_many_files/16 threads	[3.4278 µs 3.4474 µs 3.4675 µs]	[7.4527 µs 7.5142 µs 7.5674 µs]
open_many_files/32 threads	[3.9230 µs 3.9604 µs 3.9977 µs]	[6.8199 µs 6.8953 µs 6.9600 µs]

While performance improves in a current thread runtime, the results actually regress as the number of threads increases. Currently there is only one global ring in the runtime, so increasing threads may be causing lock contention.

I'll look into whether I can reduce the lock contention.

[Darksonn]

The main feedback I have here is that although it's ok to use #[cfg()] temporarily, eventually we will want --cfg tokio_uring to result in a binary that supports both io_uring and spawn_blocking. I.e. it should fall back to spawn_blocking if the Linux kernel it runs on does not support io_uring.

[mox692]

Update: Sync with master and now the base branch is 7357.