Allow to distinguish legacy CP without ETCD management via annotation

[Danil-Grigorev]

What this PR does / why we need it:

This change allows to disable ETCD certificate management and provisioning with CAPI generated certificates for legacy control planes via controlplane.cluster.x-k8s.io/legacy annotation.

This annotation is meant to be set on RKE2 CP, upgraded from 0.2.z to version 0.3+. When the child cluster does not have cluster-etcd secret created, and the <cluster-name>-etcd secret in the management cluster does not contain the external cluster.x-k8s.io/purpose label, then this cluster requires the annotation to be set.

This would ensure that automatically generated ETCD certificates by CAPI will not be used for new ETCD replicas in provisioned nodes, replacing existing set and creating 2 separate etcd groups.

This change is a followup to #449

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 #

Special notes for your reviewer:

Checklist:

• squashed commits into logical changes
• includes documentation
• adds unit tests
• adds or updates e2e tests

[Danil-Grigorev]

To perform certificate rotation https://cluster-api.sigs.k8s.io/tasks/certs/using-custom-certificates guide can be used.

In RKE2 case that would translate into requirement to collect certificates from the node filesystem, located under /var/lib/rancher/rke2/server/tls/etcd into appropriate secrets on the management cluster - https://docs.rke2.io/security/certificates?_highlight=cer#using-custom-ca-certificates

In case of ETCD, the server-ca.crt and server-ca.key should be stored in the secret under tls.crt and tls.key on the management cluster inside the <cluster-name>-etcd secret. In addition to kubeadm process, RKE2 requires to provide peer-ca set, which should be stored in the <cluster-name>-peer-etcd secret.

Performing these steps manually should convert cluster from legacy to regular, after which the annotation can be removed from the RKE2 CP object.

Implementing rancher/turtles#370 will allow to perform this operation automatically.

[Danil-Grigorev]

After some testing, it seems that upgrade from 0.2.7 to latest is safe without this change. A set of certificates is only passed on bootstrap to the nodes in case of ControlPlaneInitialized condition not being true on the cluster, so the pre-GA clusters should be safe, even with a different set of certificates stored in <cluster-name>-<purpose> secrets.

But this change is needed to allow scaling down of nodes, since CA set on management cluster which will be created, will not be equal to provisioned one, so the client will not be able to connect.