`cfg_attr(docsrs)` feature hints do not propagate to in `kube` for re-exports

[clux]

Current and expected behavior

Currently we set up some very nice doc annotations for our optional features such as ws: https://github.com/kube-rs/kube/blob/bd14267f897ae6e21ef32e83b7b5a9b8652a5044/kube-client/src/api/remote_command.rs#L100

These show up perfectly on docs.rs/kube-client

Available on crate features client and ws only.

However, on the facade crate docs.rs/kube it's less good.

Available on crate feature client only.

This leads people to be confused because they are browsing docs.rs/kube and are being slightly lied to about feature choices as seen from continued confusion in comments from bugs like: https://github.com/kube-rs/kube/issues/1159#issuecomment-1620678128

The problem arises because the ws feature flag is basically a kube-client and kube-core feature, and it's just propagated down into those crates. kube just re-exports everything it can find: https://github.com/kube-rs/kube/blob/bd14267f897ae6e21ef32e83b7b5a9b8652a5044/kube-client/src/lib.rs#L69-L109

Possible solution

Not sure exactly the best way forward here.

We could maybe try to explicitly namespace ws stuff better, but this is pretty insidious, and hard to retrofit without breaking a lot.

We could also perhaps consider importing the crates into a module workspace instead (merge the crates in one big crate). The need for having a multi-crate split is smaller these days with a locked versioning and re-exported features.

We could also just wait and hope docsrs gets better... It's not great that it doesn't detect this across crate boundaries, but it's also understandable, and probably hard. EDIT: yes. Open bug upstream https://github.com/rust-lang/rust/issues/88743 . In a similar upstream bug, they do describe why it's hard: https://github.com/rust-lang/rust/issues/83428#issuecomment-814283501

Environment

docs.rs