Introduce a platform agnostic sleep future

[AdamGS]

Which issue does this PR close?

Closes #1.

Rationale for this change

Step closer to removing tokio as a runtime dependency.

What changes are included in this PR?

New Sleep future based on futures-timer crate. It seems like a reputable crate that's used in many popular projects (like rstest and governer).

I've also bumped the rand dependency from 0.9 to 0.9.1 as there are tests that depend on a re-export of rand_core that was introduced on 0.9.1.

Are there any user-facing changes?

No. Might some async scheduling behavior subtly when running with tokio.

[AdamGS]

can't believe I forgot the license header 🤦

[AdamGS]

Now rebased on top of #515, so a step closer to making tokio optional.

[crepererum]

So instead of relying on the respective runtime e.g. tokio (which as far as I can tell is not exactly a simple mechanism.), we are now using a thread? Mmh, it's hard to say if that works under high load as intended.

Given how deeply tokio is embedded into the HTTP stack, I wonder if this whole endeavor is actually gonna lead anywhere or if that's mostly a dead end? (serious question, if you think it's worthwhile and tractable, say so)

[AdamGS]

Personally, I wish there was some standardized way to abstract over the common parts of the runtime. Tokio is great and there are many good reasons to use it but it can be quite limiting when dependencies effectively force everything around them to use it.
I haven't read through every use of Tokio in object_store, but I can imagine it being controlled by some feature flag, allowing to opt into a runtime-agnostic version

[crepererum]

Personally, I wish there was some standardized way to abstract over the common parts of the runtime. Tokio is great and there are many good reasons to use it but it can be quite limiting when dependencies effectively force everything around them to use it.

For the record: I fully agree with you on that front. I was mostly wondering if that ideal world is practical feasible at the moment given the state of the ecosystem.

As a maintainer, I would like to avoid code complexity and potential performance hits if they don't come with any benefits. And if only one of our dependencies requires tokio and there's no realistic perspective of fixing that, then avoiding tokio in object_store itself has exactly zero payoff.

I haven't read through every use of Tokio in object_store, but I can imagine it being controlled by some feature flag, allowing to opt into a runtime-agnostic version

The problem is not primarily in object_store itself. I think here we could get rid of tokio. The issue is more in the crates that we need to make object_store work in the first place. If you check out the repo locally and generate Cargo.lock (e.g. but running cargo check), then you see that basically everything depends on tokio. Now there might be feature flags for requests and Co as well, but we should probably check this before continuing with this effort.