Support async-std, or become async-runtime agnostic

[qvignaud]

Would you like to work on this feature?

maybe

What problem are you trying to solve?

We are using kube in a project that is using the async-std environment and runtime, causing to import, compile, and manage the whole tokio runtime (mostly done painlessly using async-global-executor).

While this is not a blocker nor really hard to manage in our case, it is frustrating to embed two distinct runtime, and get the cons of doing so (compile time, binary size, etc.) without having real benefits.

Describe the solution you'd like

To have crate feature like tokio and async-std allowing to tell kube what async implemetor to use where applicable, similarly to what is done in sqlx (https://github.com/launchbadge/sqlx/blob/main/Cargo.toml), or even just to not rely on any specific async runtime and let users bring their own.
I haven't checked more what are the functionnalities kube uses from tokio, so I don't know what this assumption implies in terms of workload

Describe alternatives you've considered

Currently we use kube with async-global-executor, and it works well, at the cost of compile time and binary size.

Documentation, Adoption, Migration Strategy

No response

Target crate for feature

kube-client

[nightkr]

A few things off the top of my head:

• Client is ultimately a wrapper around hyper, which hard-depends on tokio
• kube::runtime depends on tokio for its clock and to schedule Controller reconciliations onto different threads

Neither of those are insurmountable (I suppose surf would be the replacement for hyper? not completely up to date on the async-std ecosystem), but adding separate paths for both cases would be a nontrivial maintenance burden.

[clux]

hyper and tower traits would probably be the hard thing yeah. for the last two years, my position has been that the async-std ecosystem brings so little to the table (with e.g. less than 1 minor release every ~6mo) that it's not worth the maintenance burden.

we have a warning to this effect in the guide also https://kube.rs/controllers/application/#dependencies

[clux]

have initially marked this as wontfix, mainly to discourage any feature selection based solutions.

if, however, there are practical ways to become runtime agnostic, that would indeed be nice, and information that can get us moving in that direction is still appreciated.