✨ Add in-place to rollout planner

[fabriziopandini]

What this PR does / why we need it:
This PR adds the logic to handle in-place updates when performing machine deployment rollouts.

Please note that:

• Nothing changes when performing a rollout and in-place feature gate is false, or MachineSet cannot update in-place
• In place is always considered as potentially disruptive
  • in place must respect maxUnavailable
  • if maxUnavailable is zero, a new machine must be created, then as soon as there is “buffer” for in-place, in-place update is done
• when in-place is possible, the system should try to in-place update as many machines as possible.
  • maxSurge is not fully used (it is used only for scale up by one if maxUnavailable =0)
  • if there is a scale up in the middle of a rollout, creation of new machines must be limited taking into account machines that can be updated in-place.
• the implementation respects the existing set of responsibilities of each controller
  • MD ctrl manages MS
    • MD enforces maxUnavailable, maxSurge
    • As a consequence it decides when to scale up newMS, when to scale down oldMS
    • When there is a decision to scale down, MD should check if this can be done via in-place vs delete/recreate. If in-place is possible:
      • Old MS will be informed to move machines to the newMS
  • MS ctrl manages a subset of Machines
    • When scaling down, if required to move, old MS is responsible for moving a Machine to newMS (not included in this PR)
    • newMS will take over moved machine and complete the upgrade workflow (not included in this PR)
• Nothing changes when using rollout strategy on delete
• With this PR, we are now testing about 1.4k rollout scenarios!
• The current PR always assumes that MachineSet cannot update in-place (this will be changed by a follow up PR)

Which issue(s) this PR fixes:
Part of #12291

/area machinedeployment

[fabriziopandini]

/test pull-cluster-api-e2e-main

[alexander-demicev]

thanks a lot for taking care of this

[fabriziopandini]

/test pull-cluster-api-e2e-main

[sbueringer]

Great work, thank you!

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 23d69c986166e5b6b5874ee59dd6649ad338a0a9

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sbueringer

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 [sbueringer]

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