feat: be able to import any k8s obj as source

[guilhem]

This pull request introduces several significant changes to the kustomization_controller to enhance the discovery and handling of source references, as well as adding new tests to ensure functionality. The most important changes include adding a DiscoveryClient to the KustomizationReconciler, refactoring the source retrieval logic, and adding a new test for the SourceRefAPIVersion.

Enhancements to KustomizationReconciler:

• Added DiscoveryClient to the KustomizationReconciler struct for dynamic API discovery. (internal/controller/kustomization_controller.go)
• Introduced the Source type and refactored the getSource method to use unstructured.Unstructured for dynamic API version handling. (internal/controller/kustomization_controller.go)

Codebase updates:

• Updated imports to include discovery package in multiple files. (internal/controller/kustomization_controller.go, internal/controller/suite_test.go, main.go) [1] [2] [3]
• Modified the main function to initialize DiscoveryClient and pass it to the KustomizationReconciler. (main.go)

Testing improvements:

• Added TestKustomizationReconciler_SourceRefAPIVersion to verify the correct handling of SourceRef API versions. (internal/controller/kustomization_controller_test.go)
• Updated the test suite setup to include DiscoveryClient. (internal/controller/suite_test.go)

[matheuscscp]

Hi @guilhem, thanks for this PR. This change is far more complex than this PR sounds and must be discussed in the Flux dev meetings, which are open. Feel free to join one of the meetings in the new year if you want to discuss about this change: https://fluxcd.io/community/#meetings

[guilhem]

Hi @guilhem, thanks for this PR. This change is far more complex than this PR sounds and must be discussed in the Flux dev meetings, which are open. Feel free to join one of the meetings in the new year if you want to discuss about this change: https://fluxcd.io/community/#meetings

Thanks @matheuscscp and after some time and reflection, I don't even think it's a good way to do it.
The main problem is with watching resources for reconciliation, and I don't see any simple way to solve it.
The other is with spec/status standardisation. Status.Artifact is not really something I like.

In fact, I tried to keep this PR as small as possible, but I think there is a far better way to do:
Having a dedicated "artifact" and "artifact set" objects.

But let's talk about it in a meeting. I can also talk about why we try to have something like that :)

[guilhem]

But it was a good way to understand links between objects ;)