Revert "fs: avoid lock acquisition after uring init"

[Darksonn]

Please don't add new dependencies without a very strong justification. In the case of once_cell, this is actually a crate we have removed previously when it bumped its MSRV and broke ours.

Reverts #7843

cc @tahmid-23

[tahmid-23]

no leniency for unstable dep? 🙁 unfortunate that other solutions are uglier

[Darksonn]

No, sorry. But you can reintroduce our custom OnceCell implementation from #5048 / #7208.

[tahmid-23]

it's insufficient without reimplementing OnceState, requires a private poisoning method.

[Darksonn]

Could you use our async implementation from tokio::sync::OnceCell? It doesn't seem like it would be an issue to make check_and_init into an async function. If you need to block on init in the IO driver, you can use crate::future::block_on for those cases (but my guess is that the non-async get is sufficient outside of the checks in async fns in tokio::fs).