feat(crd-generator): Allow to configure CRDGenerator if running as annotation processor, add approval and compiler tests

[baloo42]

Description

• Allow to configure CRDGenerator if running as annotation processor:
  • Read options from compiler options and crd-generator.properties
  • Allow to configure...
    • parallel generation
    • CRD versions (v1, v1beta1)
    • outputPath
    • header in output files
    • describeTypes (debug output)
    • additional labels
    • additional annotations
• Add approval tests to replace custom assertions for some kind of approval tests
  CRDGenerator: Replace assertions with ApprovalTests #5850
• Add compiler tests with approvals for E2E tests (includes parallel testing)
  see fix(crd-generator): Fail if multiple versions are marked as stored #5846 (comment)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[baloo42]

TBD:

• I used Approval Tests in two cases: In unit tests of the api module and for the compiler tests in the apt module. Please review the setup in detail as I haven't used it before.
• There are now two modules which test the CustomResourceAnnotationProcessor in an own maven module.
  This approach was really error prone to me and that's the main reason why I wrote the compiler integration tests with google's compile-testing. In my opinion we can remove the test and test-parallel module. What do you think?
• There are some public static final flags: Are they required? e.g. DESCRIBE_TYPE_DEFS
• There are now some duplicate unit tests because those cases are also tested by the approval tests. Should I remove them in this PR or do you want me to wait with the deletion?
• The option parsing is implemented in a very simple way. Is it enough? (If we extract an interface / factories, it would be also easier to test)

[sonarqubecloud]

Quality Gate failed

Failed conditions
78.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[andreaTP]

I skimmed through it and the changes look to be going in a nice direction, but this is massive, either you manage to chunk it into more digestible bites or it will take some time to properly review.

cc. @shawkins asking for help here 🆘

[baloo42]

A third of the changes come from the copy of the test module to the new test-parallel module. (It's exactly the same content). So the first question is, do we want to keep both test modules? ...if we have an alternative:

I don't like both because it requires a lot (test case) duplications, but it's some kind of a real end-2-end test and it was there before I started contributing. My suggestion would be to replace those both modules by appropriate "compile-testing" tests in the apt module. With a small abstraction we can build easily tests which run always with parallel mode on and off (and I think we can also run them in parallel via failsafe plugin because they are fully isolated).

Regarding the options:
Implementing more apt processor options requires tests. We would require a lot of modules to test them if we don't change the test strategy. And in the end, I need it for #5794 because here we have to implement a way to configure a ca certificate.

I'm happy to hear any further suggestions or guidence ;)

[baloo42]

Can probably be closed. See #5885 (comment)