Refactor the upgrade process to stop using config on upgrade

[xmudrii]

What this PR does / why we need it:

This PR refactors the cluster upgrade process to adhere to recommendations from the upstream community. With that, using the --config flag along with the kubeadm upgrade apply command:

• is strictly discouraged because of possible side effects affecting the cluster stability
• is deprecated and partially removed as of Kubernetes 1.30 and will be completely removed with Kubernetes 1.31

kubeadm writes configuration to different ConfigMaps in the kube-system namespace, mainly kubeadm-config, kubelet-config, and kube-proxy. The recommended workflow is to update the needed ConfigMap and then run the appropriate kubeadm command as described in the document.

Upon initiating the upgrade process, KubeOne will build the Kubernetes clientset, generate new Kubeadm configs and update all the ConfigMaps used by Kubeadm. Kubeadm will reconfigure the cluster as needed based on what's changed (if anything is changed at all).

This however means that some options are now immutable, but most of them should not be user-facing, and I don't think we ever supported changing these options:

• Anything in InitConfiguration and JoinConfiguration structs. There is .LocalAPIEndpoint.AdvertiseAddress, but I don't think we support changing the IP address of existing control plane or worker nodes

Which issue(s) this PR fixes:
xref #3205

What type of PR is this?

/kind feature
/kind design

Special notes for your reviewer:

In the future, we should refactor the force upgrade process to work in a reconciliation manner, i.e. to avoid running the full upgrade process, but only compare what's changed and regenerate only those affected manifests.

Does this PR introduce a user-facing change? Then add your Release Note here:

Refactor the cluster upgrade process to adhere to the [Kubernetes recommendations](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure/) by updating ConfigMaps used by Kubeadm instead of providing the full config to Kubeadm itself. This change should not have any effect to cluster upgrades, but if you encounter any issue, please create an issue in our repository

Documentation:

NONE

[kubermatic-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[xmudrii]

/test all

[kron4eg]

All in all, I like the idea.

[xmudrii]

/cherrypick release/v1.8

[kubermatic-bot]

@xmudrii: once the present PR merges, I will cherry-pick it on top of release/v1.8 in a new PR and assign it to you.

In response to this:

/cherrypick release/v1.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kron4eg]

/lgtm
/approve

[kubermatic-bot]

LGTM label has been added.

Git tree hash: 20d9d6a9ae373f0a41cf2dc083f1f5ee8ec94eda

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kron4eg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [kron4eg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubermatic-bot]

@xmudrii: new pull request created: #3253

In response to this:

/cherrypick release/v1.8

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.