fs: avoid lock acquisition after uring init

[tahmid-23]

Motivation

#7815 added a lock acquisition after the uring had been initialized. This negates the point of the atomic state variable. However, we need to mutably initialize the Probe once. This sounds exactly like a use case for OnceCell / OnceLock.

Instead of an atomic indicating the uring state, we use a OnceCell<Option<Probe>> to indicate the uring state: None indicating it being unsupported, and the Probe indicating successful initialization. (This Probe could later be replaced with any other necessary readonly uring state, but this is currently the only necessary type.)

Although we would like to use std's OnceLock, its get_or_try_init method is currently unstable. We cannot implement it ourselves (as previously present), since OnceState::poison is not public and is necessary to implement get_or_try_init. Hence, I added once_cell as a dependency under the io_uring feature. The 1.65 MSRV should be compatible anyway.

[ADD-SP]

Thanks!