Evaluate what kind of Keycloak operator should be supported

[fabiobrz]

The Keycloak operator implementation is transitioning from a legacy to a Quarkus operator extension one, see https://www.keycloak.org/2022/09/operator-crs

At the moment there is no support in Intersmash for the "New" Keycloak operator, while the current codebase would support the old one.
We need to decide which path to follow regarding provisioning Keycloak via the Operator.

• Using the new operator would most likely mean to generate the Java model from existing CRDs [1], implement a new KeycloakRealmImportProvisioner and align testsuite implementation to cover it, i.e. based on the Keycloak and KeycloakRealmImport CRDs. The current KeycloakOperatorProvisioner could be temporarily deprecated, until more CRDs are added to the new perator and we verify how the existing implementation works with them.
  PROs: we're aligned with latest, no need to build and push any images. CONs: existing tests relying on missing CRDs won't work.

• Using the old operator would mean to create a bundle image and an index one that we should maintain and push to some registry, similarly to what is being evaluated for the ActiveMQ Artemis operator provisioner.
  PROs: existing tests relying on missing CRDs will work. CONs: create the images and push tem, not aligned with latest implementation

This issue tracks the effort needed to investigate and identify a solution that can satisfy as many requirements as possible in the context of Keycloak operator based provisioning, but a viable option would also to get to a quick solution in order to enable the testsuite, and then to an ultimate one, later.

---

• Environment: testuite/keycloak provisioning
• Steps to reproduce: N/A

[tommaso-borgato]

WIP in #57

[tommaso-borgato]

we have two option:

• use the old custom resources with the new operator by using yet another operator which "translates" old custom resources into new custom resources: we'd end up using two operators
• use the new operator with the new custom resources which are not final yet

we chose the second option which is implemented in #57