Allow removing hyper-rustls/ring feature

[eliad-wiz]

Motivation

no reason to include the "ring" crate if aws-lc-rs is being used.

Solution

features are only additive, so they can't be removed once it's added (by any sub-crate).
avoid adding extra features that might not be used (e.g. in case of aws-lc-rs).

in order to make it optional we can add a new "ring" feature to the default features, so it can be avoided with default-features = false. however, i think letting the configure it as needed is a better approach.

please update if you do prefer to add a new default feature-flag (or some other approach) and i'll adjust the patch.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.1%. Comparing base (ab488ae) to head (bba11ca).
Report is 2 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1717   +/-   ##
=====================================
  Coverage   76.1%   76.1%           
=====================================
  Files         84      84           
  Lines       7859    7859           
=====================================
  Hits        5976    5976           
  Misses      1883    1883           

Files with missing lines	Coverage Δ
kube-client/src/client/auth/oidc.rs	56.4% <ø> (ø)

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[clux]

i think we need (when using rustls);

• one of aws-lc-rs or ring
• webpki-roots optional, but orthogonal to this choice (so probably does not need to be checked here)

[eliad-wiz]

see my previous comment.
let's try adding cfg-if to make it a bit clearer

[clux]

i think we can avoid this extra change and dependency, and keep all logic as we had it before by introducing the new compile error up to top level (257 in oidc.rs).

#[cfg(all(feature = "rustls-tls", not(any(feature = "ring", feature = "aws-lc-rs"))))]
compile_error!("At least one of ring or aws-lc-rs feature must be enabled to use rustls-tls feature");

[clux]

mostly because the way it's indented now is also quite big and hard to extend, and we want to just bail out as soon as possible anyway.

besides, oidc.rs isn't even the client that is used for most things (that one comes from config_ext.rs + builder.rs and does the selection in tls.rs (which does not do this same if-else on providers).

[eliad-wiz]

done.

btw, are you fine with removing the auto-installation of the aws-lc-rs provider if aws-lc-rs feature was set?
theoretically both ring and aws-lc-rs might be enabled, and we should leave it to the user (or let rustls install if only one of them was selected)

[clux]

removing auto-installation

not super comfortable touching this yet. removing it outright will feel breaking, and it's a very low level api people will have to familiarise themselves with to do basic things when using aws-lc-rs. if aws-lc-rs becomes the default, i would want it to be frictionless, and this feels ok to me as a 'helping hand'; install if it hasn't been installed already. nothing stops people from installing another default provider else earlier on.

this might turn into a bigger discussion though. maybe we need to do the same thing we did for openssl vs rustls; always speculatively install one provider, tilting towards our default. that way we can change our default later on (like we did for openssl -> rustls).

[clux]

Suggested change

	default = ["client", "ring"]
	default = ["client", "rustls-tls", "ring"]

possibly worth listing this explicitly. EDIT: ah, but it's explicit in kube/Cargo.toml

[clux]

Thanks a lot. Sorry about all the back and forths. I'll get this in before the release.

[clux]

minor follow-up #1720