Move core operators into operator-rs #842

I propose to move our core operators (commons-operator, listener-operator, and secret-operator) into the https://github.com/stackabletech/operator-rs repository. This topic was brought up multiple times in the past, also briefly during our last on-site. The reasoning to do this is as follows:

• Expose core operator specific code (which needs to be consumed by other parts of our platform) as library code owned by the individual operators instead of defining it as part of shared code in stackable-operator. This puts control of operator specific consumer code back to where it belongs - close to the core operators.

  An example: Recently, secret-operator introduces a new annotation on the secret volume with which consumers can request specific parts of secret data. The two different modes are defined via an enum in secret-operator.

  On the other hand, the stackable-operator library provides a SecretClassVolumeBuilder which allows downstream product operators to easily create secret-operator compatible volumes and mounts. This piece of code wants to make it mandatory for callers to specify the mode the volume should be provisioned with.

  For this to happen, the enum has to be moved into the stackable-operator crate, away from the authoritative source of truth - the secret-operator. Further, if we ever decide to add a third variant to the enum, we are now forced to do a stackable-operator release to be able to use the updated enum in secret-operator. The relationship of dependencies is completely reversed in this case.

• Streamline the design and rollout of new or changed APIs in our core operators. Many changes in library code (not only stackable-operator, but also other crates) can more easily be tested on core operators. This increases the iteration speed and cuts down on unnecessary rounds of follow-up releases when the APIs for a particular feature are tweaked.

• Move CRD definition and versioning to operators responsible for these resources. The core operators decide how they evolve their user API, not the framework.

• Reduce maintenance effort, especially introduced by templating rollouts. Common config can now be managed in one repository instead of four.

There are a bunch of tasks which need to be done and planned when migrating the code of our core operators into a single repository. These tasks include, but are not limited to:

• Define the repository structure. Where should code and surrounding files for each operator live. A structure could roughly look like this:

  (root)
  |
  |- crates
  |  |
  |  |- cert-tool             (bin) # renamed from cert-tools
  |  |- krb5-provision-keytab (bin)
  |  |- commons-core          (lib)
  |  |- commons-operator      (bin)
  |  |- listener-core         (lib)
  |  |- listener-operator     (bin) # csi-grpc moves into here
  |  |- listener-olm-deployer (bin)
  |  |- secret-core           (lib)
  |  |- secret-operator       (bin) # utils moves into here
  |  |- secret-olm-deployer   (bin)
  |  |- stackable-certs       (lib) # p12 could be moved into here
  |  |- stackable-*           (lib) # all existing stackable-* crates
  |  |- k8s-version           (lib) # also already exists
  

  Accompanying code like Helm templates, Dockerfiles, scripts, docs, changelogs, READMEs, and tests will live in the *-operator directories.

• The CI pipelines now need to handle building and testing the binaries. Most of the existing pipelines can be re-used as is, only with slight adjustments.

• The Tiltfile needs to be adjusted so that it can find the individual operator paths and run the appropriate sub Tiltfiles. Something like https://docs.tilt.dev/api.html#api.config.define_string seems useful to enable commands like tilt up -- --operator secret. The Makefile could forward the identifier.

• The Antora config needs to be adjusted to find the new doc locations.

• The operator-templating needs to either exclude these core operators entirely, or needs the ability to point at subpaths in a repository.