Implement upgrade individual resources for managed topologies

[fabriziopandini]

Detailed Description

This is part of the activities for the implementation of the ClusterClass proposal. Anything else you would like to add:

#4998 and #4999 started the implementation the logic for computing the desired state of a managed topology, however, both issues does not include implementing support for version upgrade component by component.

This issue, which can be implemented only after the aforementioned issues are merged, address this GAP by defining the following rules; it is also assumed the changes to the control plane contract introduced by #4949 are in place:

• when computing the desired state for the control plane object

  • if controlPlane current version < cluster.topology.version and all the machine deployments are of the same version of the control plane
    • controlPlane = cluster.topology.version

• when computing the desired state for the machine deployments object

  • if machine deployment current version < cluster.topology.version and the control plane is upgraded (1) and previous machine deployment (2) are upgraded (3)
    • machine deployment = cluster.topology.version

(1) According to the proposed changes to the contract, this means control plane spec.version == status.version
(2) This implies to use a consistent and predictable ordering in processing machine deployments (e.g order by name)
(3) This can be determined by looking at the machine deployment status or at the underlying machines.

/kind feature

[fabriziopandini]

/milestone v0.4

[sbueringer]

/assign

[sbueringer]

/area topology

[ykakarap]

/assign

[vincepri]

Renamed a bit to avoid using "component", which usually refers to artifacts in the release