kube super-crate

[clux]

Something I've been wanting for a long time, but have been put up because of how it's going to be done.

Raising it again now, because once there's some agreement on delineation in #642, we ought to do this to fix dependabot issues (users get dependabot issues for kube and kube_runtime separately, which is incompatible with our versioning policy).

• Failed attempt: through exposing Api as an async trait: see Make an async_trait for Api trait to remove kube dependency from kube-runtime #592
• Likely route: pull api and config modules into one or two new crates
• Import new crate(s) from kube
• Can now re-export kube-runtime from kube under a runtime feature

=> kube is a facade crate only the only thing users depend on

[nightkr]

👍 for me. One thing that we've ran inte at @stackabletech is that derive macros make facades a bit tricky. Essentially, the macro has no idea about whether to refer to the traits that it interacts with using the original crate (which means that everyone still needs to pull in the direct dependency) or the facade crate (preventing direct imports which allow cargo to optimize compilation slightly).

One way to work around this would be to have an attribute for overriding the path to kube (and any other crates used).

[clux]

this was released in 0.62.0 🎉