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