🐛 patch managed fields after clusterctl move so that it does not own all fields

[ykakarap]

What this PR does / why we need it:

This PR patches the managed fields so that clusterctl does not own all the fields in the object.
Note: The last step of move is unpausing the cluster. So clusterctl still ownes the .spec.paused field on the Clusters and the cluster.x-k8s.io/paused annotation on the ClusterClasses.
So if someone tries to unpause the cluster using SSA it will throw a conflict.

❯ k --kubeconfig docker-cluster-one.kubeconfig apply -f cluster-unpuase.yaml --server-side=true
error: Apply failed with 1 conflict: conflict with "clusterctl" using cluster.x-k8s.io/v1beta1: .spec.paused
Please review the fields above--they currently have other managers. Here
are the ways you can resolve this warning:
* If you intend to manage all of these fields, please re-run the apply
  command with the `--force-conflicts` flag.
* If you do not intend to manage all of the fields, please edit your
  manifest to remove references to the fields that should keep their
  current managers.
* You may co-own fields by updating your manifest to match the existing
  value; in this case, you'll become the manager if the other manager(s)
  stop managing the field (remove it from their configuration).
See https://kubernetes.io/docs/reference/using-api/server-side-apply/#conflicts

TODO:

• Unit ( out unit tests in move use fake client which do not have managed fields to begin with so I am not sure how to unit test this where the test is meaningful)

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #7473

[sbueringer]

Unit ( out unit tests in move use fake client which do not have managed fields to begin with so I am not sure how to unit test this where the test is meaningful)

Can we do this by extending our self_hosted e2e test instead?

Basically we should check e.g. the Cluster & ClusterClass that clusterctl doesn't own any fields (after "Moving the cluster to self hosted")

I would be totally fine with doing this in a follow-up PR to get this bugfix in time for the next v1.3 beta and v1.2.5

[fabriziopandini]

Only one nit from my side
+1 to test this by extending our self_hosted e2e test in a follow up PR (unit testing this with fake client isn't possible)

[ykakarap]

+1 to covering this in E2E tests.

[ykakarap]

Opened an issue to track the E2E work: #7510

[sbueringer]

/test pull-cluster-api-e2e-full-main

[sbueringer]

/lgtm

[sbueringer]

/cherry-pick release-1.2
(bugfix)

[k8s-infra-cherrypick-robot]

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

In response to this:

/cherry-pick release-1.2
(bugfix)

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.

[sbueringer]

/approve

[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

[k8s-infra-cherrypick-robot]

@sbueringer: new pull request created: #7512

In response to this:

/cherry-pick release-1.2
(bugfix)

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.