Deprecate ResourceExt::name in favour of safe name_* alternatives

[clux]

Due to the general awkwardness of having a potentially panicking ::name() method front and center even though it is generally safe to use. See #634 for initial discussion, and #942 for the most recent confusion.

This adds:

• ResourceExt::name_any providing a short & safe drop-in replacement for name() (can return empty string) for loggers
• ResourceExt::name_unchecked where we explicitly want a crash on missing name (like internally in runtime::reflector)

Now the relevant docs from ResourceExt looks like:

Then ran a lot of fastmod to replace in the codebase. Have set the removal of ::name to the deprecation length we used for runtime's try_flattens; removing on the 4th minor.

Plan

Long term we can remove .name() and maybe reintroduce it later as an option shorthand for .meta().name instead.

edited out comments

It is also possible we can make ::name a non-panicing variant:

self.name.unwrap_or_else(||self.generateName).unwrap_or("<unknown>")

Not sure if this is wise. But it would be nice to have something short for all the standard log gunk where this stuff is inevitably used most of the time.

EDIT: this is added under ::name_any

EDIT: removedResourceExt::name_or_generatename.

[codecov-commenter]

Codecov Report

Merging #945 (adf2875) into master (9f1df5e) will decrease coverage by 0.03%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #945      +/-   ##
==========================================
- Coverage   72.47%   72.43%   -0.04%     
==========================================
  Files          64       64              
  Lines        4399     4412      +13     
==========================================
+ Hits         3188     3196       +8     
- Misses       1211     1216       +5     

Impacted Files	Coverage Δ
kube-core/src/admission.rs	61.11% <ø> (ø)
kube-core/src/resource.rs	46.51% <33.33%> (-0.99%)	⬇️
kube-core/src/params.rs	77.69% <100.00%> (ø)
kube-runtime/src/reflector/object_ref.rs	67.07% <100.00%> (ø)
kube-runtime/src/wait.rs	69.81% <0.00%> (-1.89%)	⬇️
kube-client/src/client/mod.rs	68.55% <0.00%> (+0.60%)	⬆️
kube-client/src/client/upgrade.rs	81.48% <0.00%> (+3.22%)	⬆️

[nightkr]

Hm, not sure I see a lot of value in exposing name_or_generatename separately from name_any. It might also be worth adding a tag to name_any for the fallback cases, so we get something like my-deployment-abcde-abcde (name is present), my-deployment-abcde-(id) (fallback to generate_name), or (unnamed) (neither name nor generate_name are present).

[clux]

Well, that's also one of the reasons i exposed name_or_generatename so that users can do:

obj.name_or_generatename().unwrap_or_else(||"(unnamed)") 

or whatever constant they want. i think the majority use case for the _any case is going to be quick logging rather than precise defaults, so am not super keen on making the weird use case a mandatory thing to think about. empty string returned on both missing is kind of ok when we are being imprecise - as implied by the _any suffix.

[clux]

maybe a ::name_or("(unnamed)") would be sensible rather than name_or_generatename?

[nightkr]

Yeah, I agree that it's kind of a weird special case. I just don't see what other use case there is where you don't care at all about the distinction between name and genname.

[clux]

Yeah, that's a good point. I have removed name_or_generatename. If people don't care about whether they get name or generateName, they probably can just use name_any.

[nightkr]

Both the warned-about types should be safe to derive Eq for as far as I can tell.