🌱 Automatically set kubelet args for capd

[fabriziopandini]

What this PR does / why we need it:
This PR uses the kind mapper introduced by #8880, and use it to automatically set some parameters in the node registration, so the kindest/node image are started as expected.

Which issue(s) this PR fixes:
Fixes #

[fabriziopandini]

/hold
for #8880

[killianmuldoon]

Part of #8788

[sbueringer]

@fabriziopandini I think this is an old version of the kind mapper PR. Did you maybe lose a commit during rebase?

[fabriziopandini]

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

[fabriziopandini]

/hold cancel
@sbueringer @killianmuldoon I also updated E2E templates, CAPD templates, docs
Ignition is now a documented exception where the user has to set manually kubeletExtraArgs id using CAPD; The E2E template is an example of how this can be done

I have grouped changes in different commits for a faster review

[sbueringer]

/lgtm
/approve

/hold
for squash

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: f657dc1aa2e0e2d65b6b866da5276968358cb021

[invidian]

It seems to me that adding all this code here, including kindMapping kind.Mapping adds a lot of unnecessary complexity to the solution, as this code has nothing to do with writeFilesAction functionality.

Given that we already have plenty of code duplicated between CloudInit and Ignition code for CAPD, I'd suggest to introduce some intermediate, common format which you can convert both CloudInit and Ignition custom data to to perform CAPD-specific mutations + deduplicate code responsible for converting it into provisioning commands.

Format can be as simple as needed, so something like:

type File struct {
  Path string
  Mode string
  Contents string // Or []byte
}

type ProvisioningData struct {
  Files []File
  Commands []provisioning.Cmd
}

Then you can have a function ProvisioningData -> ProvisioningData, which will apply CAPD specific modifications and []File -> []provisioning.Cmd function to convert all files into creation commands.

This also obliviously enables us to reuse flags modifications between cloud init and Ignition and makes it all very easy to test as it's all data-driven.

[fabriziopandini]

Finding the best way forward for sharing common code if any is in scope of #8907

This PR scope is to get us in a place where we are less exposed to the impact of changes in the kindest/image, see #8788 for the full context about impact of the latest dump and all the work that followed

[fabriziopandini]

squashed commits
running all E2E tests for one time more
/test pull-cluster-api-e2e-full-main

[fabriziopandini]

/test pull-cluster-api-test-main

[killianmuldoon]

This is complex, but actually less complex than the current state of spreading these changes across multiple templates. I think there's probably room for further simplification, but really a good change.

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 1dd663dd5f89722192912ba2421d59b9238a0e49

[sbueringer]

e2e-full failed

re-triggering. Let's definitely wait until it's green before merge

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

[sbueringer]

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

to get more data on the test failures

[fabriziopandini]

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

[fabriziopandini]

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

[sbueringer]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 0bc19f1a328076743e0e3342aa04303eca2b252c

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: killianmuldoon, 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 [killianmuldoon,sbueringer]

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

[sbueringer]

/hold cancel

[killianmuldoon]

/area provider/infrastructure-docker