fix: kube-core::Schema hoisting logic

[NickLarsenNZ]

Fixes #1821

This updates the kube Schema hoisting since schemars Schema's have changed.

• Add tests for a variety of enum use-cases:
  • Tagged vs Untagged
  • Unit vs Tuple vs Structural variants
  • With and without doc-comments (descriptions)
• Rewrite the hoisting logic
  • This is annotated with dev-comments to help understand intend and to ease future schemars changes.

This also fixes other issues that appeared along the way:

• Untagged enum variant doc-comments were being applied to field descriptions.
• Additional null entry added to enums.

See also: stackabletech#1, where this work was originally done.

---

Motivation

Since kube 1.0.0, schemas became invalid when optional enums contained comments on the variants.

Solution

• Break out the hoisting logic into separate modules with scoped tests.
  • Heavily document the steps to help developers with future schemars Schema generation changes.
• Add tests to try and catch this in future.

[codecov]

Codecov Report

❌ Patch coverage is 96.65272% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.2%. Comparing base (b14f3d7) to head (221510e).

Files with missing lines	Patch %	Lines
kube-core/src/schema/transform_any_of.rs	91.7%	3 Missing ⚠️
kube-core/src/schema/transform_one_of.rs	90.4%	3 Missing ⚠️
kube-core/src/schema/transform_properties.rs	97.4%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1839     +/-   ##
=======================================
+ Coverage   74.6%   75.2%   +0.6%     
=======================================
  Files         84      90      +6     
  Lines       7910    8083    +173     
=======================================
+ Hits        5900    6071    +171     
- Misses      2010    2012      +2     

Files with missing lines	Coverage Δ
kube-core/src/schema/mod.rs	100.0% <100.0%> (ø)
...re/src/schema/transform_optional_enum_with_null.rs	100.0% <100.0%> (ø)
kube-derive/src/custom_resource.rs	83.9% <100.0%> (-<0.1%)	⬇️
kube-derive/tests/crd_complex_enum_tests.rs	100.0% <100.0%> (ø)
kube-derive/tests/crd_mixed_enum_test.rs	100.0% <100.0%> (ø)
kube-derive/tests/crd_schema_test.rs	100.0% <100.0%> (ø)
kube-derive/tests/crd_top_level_enum_test.rs	100.0% <ø> (ø)
kube-core/src/schema/transform_properties.rs	97.4% <97.4%> (ø)
kube-core/src/schema/transform_any_of.rs	91.7% <91.7%> (ø)
kube-core/src/schema/transform_one_of.rs	90.4% <90.4%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[NickLarsenNZ]

I'm unsure what to do about the CI error:

error: rustc 1.86.0 is not supported by the following package:
  home@0.5.12 requires rustc 1.88

For me, I get home@0.5.9. Should I pin the dependency?

kube/Cargo.toml

Line 50 in 7c63f56

home = "0.5.4"

[sbernauer]

Created #1840 to address the home CI failures

[Techassi]

I've just synced this PR branch to include the CI fixes (done in #1840). This PR should now be ready for review.

[NickLarsenNZ]

Hi @clux, are you able to take a look at this?

We saw a new PR come up that fixes part of the problem: #1853

[sbernauer]

(Also a small draft PR with a fix popped up: #1841)

[clux]

Heyyy, sorry not had much time to deeply look at things the last month. This is definitely on the larger size, so only done a quick pass now, but the testing rigor is definitely super helpful! Thanks a lot for all this.

One thing that stands out as different in the approaches here is the use of Transform impls; this PR calls multiple functions, in one giant Transform, and the new PR is adding a more isolated option enum transform. I do wonder if it's better to follow the multiples-transform approach to allow users some flexibility (without us having to expose a bunch more config parameters for "our kube rewriter"). I have a hunch that it can make testing a bit more isolatable as well perhaps, but maybe not.

As a quick check first. Would you be OK with rebasing (possibly also splitting to expedite) this if I were to merge #1853 first? That's a pretty digestible PR, although it does seem to clash with your remove_optional_enum_null_variant parts (for which the optional_enum_with_null tests would probably be useful to combine).