Kubernetes-ready installation of the server

[cbosdo]

Installing Uyuni server on Kubernetes may not need an operator in the end.
The idea of this card / EPIC is to delegate the update / setup to initContainers. Basically the server container would run the setup as an initialization container, the DB upgrade and finalization as other init containers.
There are some assumptions for this to work:

1. those containers should be just checks if nothing needs to be done.
2. if the setup variables are changed, the container needs to be adapted (calling spacewalk-hostname-rename or satpasswd if needed).
3. each container deals with its upgrade steps.
4. if a dependent upgrade or setup failed, the other container needs to fail too.

Achieving this means that we have full control of what happens during the setup and upgrade phases.
While this is currently the case for upgrade it is far from being the case for the setup.
A preliminary task is to simplify and de-clutter the setup scripts in order to write more meaningful setup.

With this Uyuni server would only need to be a helm chart and mgradm could be limited to operate on the cluster to help migrating from a legacy server.

May be some of the YAML files generated by the helm chart could be used with podman kube play and quadlets... but that is another EPIC.

[cbosdo]

@admd @rjmateus this idea may be of interest for you

[rjmateus]

It looks interesting and is something we definitely need to research about. But not for 5.1, we are already too loaded.
The good think is that podman deployment is hidden on mgradm, so we can change all the pipes in a Major version, without many vivibility to customers.