Make control plane endpoint default registration method

[Danil-Grigorev]

What this PR does / why we need it:
Fixes: #343

From the list of available registration methods, control plane one seems to be the most suitable for a default. It will not work for all cases, but for those which do, namely clusters without restrictions on accessing public API and address of CP endpoint, this should work out of the box as a quickstart method.

Users may decide to define a different registrationMethod, where one edit of the value is intentionally allowed.

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

[furkatgofurov7]

This needs an update as discussed offline with @Danil-Grigorev, please hold off merging it manually.

[Danil-Grigorev]

Upon checking crust-gather archive after test run, it seems the field is emptied, as expected. Just added e2e tests after all, leaving the rest of the logic unchanged. Should be good to merge now @furkatgofurov7 @salasberryfin, as this addressed my concern.

spec:
  agentConfig:
    additionalUserData: {}
    format: cloud-config
    nodeAnnotations:
      test: 'true'
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: DockerMachineTemplate
    name: caprke2-e2e-yqwygg-control-plane
  machineTemplate:
    infrastructureRef: {}
    metadata: {}
  manifestsConfigMapReference: {}
  nodeDrainTimeout: 30s
  privateRegistriesConfig: {}
  replicas: 1
  rolloutStrategy:
    rollingUpdate:
      maxSurge: 1
    type: RollingUpdate
  serverConfig:
    disableComponents:
      kubernetesComponents:
      - cloudController
    etcd:
      backupConfig: {}
  version: v1.28.12+rke2r1
status:
…

[anmazzotti]

If I read this correctly, an empty registrationMethod value is now equivalent to control-plane-endpoint, but it allows replacement, which should solve indeed my original issue.

I still wonder however if this is going to create race conditions, what if I don't want to use the control-plane-endpoint as registration method, but I want to directly use an address and input that address as variable in a cluster class? I don't see any example of this in the PR.

I wonder if it's possible to put the control plane on "pause" until the registrationMethod is populated, but this seems to be an improvement.

[alexander-demicev]

LGTM, lets wait and see if @furkatgofurov7 has any other concerns

[furkatgofurov7]

I would be in favor of not duplicating this since it is a one liner less compared to the original cluster template we have in the repo, however, it looks like bigger of a change to achieve this (using jinja templating or Go's templating capabilites) vs benefits it brings.