New ClusterClass (without legacy feature porting)

[mxmxchere]

Currently, especially in #11 we are porting the old state of the cluster-api resources implemented here. After the porting is done we should create a new cluster-class from scratch that is focussed on delivering the best user experience and to adhere to the proposed best practices for clusterclass definitions. Differences from the current approach:

• no helm templating
• no included scripts
• no apt commands / use k8s-version and k8s-binaries shipped with the image
• no prefix/suffixing of machines
• no namespacing (see provider contract/best practice)

[jschoone]

@paulphys, @mxmxchere and I had a good session on building cluster stacks for Kubernetes 1.28, see https://github.com/SovereignCloudStack/cluster-stacks/tree/feat/kubernetes_128 We completely removed the apt stiff in the pre and postKubeadmCommands and remove the included scripts. Also we understood the different places where it is possible to set versions better, e.g. cluster.spec.topology.version, which we try to utilize for image selection. We need to continue stripping down the config and then see which files are required to be included again, because currently the scripts like etcd defrag, tweak-kubeapi-memlimit and containerd are available in the repo but not included via Helm.

Next steps are currently:

• [x] set cloudName to default openstack
• [x] set secret to default `openstack
• [x] remove not needed suffixes
• [ ] remove not needed prefixes
• [ ] make use the cluster.spec.topology.version
• [ ] discover again the scripts and see which needs to be included again

[paulphys]

I went ahead and deleted all mentions of generational suffixes used in worker and control plane. Not sure what to do with suffixes like -md-0-no1 found in cluster-class.yml and other places.

[mxmxchere]

can be dropped i'd say. This is our attempt to build a clusterclass with a new and clean approach with as little unneeded additions as possible