🐛 Fix ClusterClass MachinePool rollout on BootstrapConfig changes

[bnallapeta]

What this PR does / why we need it:
ClusterClass-managed MachinePools were not triggering node rollouts when BootstrapConfig or InfrastructureMachinePool templates changed. This happened because updateMachinePool() used reconcileReferencedObject() which patches objects in-place without changing their names. Infrastructure providers (like CAPA) watch for configRef.name changes to trigger rollouts, but since the name never changed, no rollout occurred.

This PR changes updateMachinePool() to use reconcileReferencedTemplate() instead. This is the same approach used by updateMachineDeployment().

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 #10496

/area machinepool
/area clusterclass

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign joelspeed for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

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

[bnallapeta]

@richardcase @AndiDog
Please take a look at this. I am in the process of manually testing this and will write e2e. But, early feedback on the approach will help.

[mpinchover]

Just curious, why are we creating an inline function instead of defining it somewhere else? Not as familiar with Kubernetes code bases so disregard if there there's a good reason.

[bnallapeta]

a. I'd like to stay consistent with the current style where this is used in multiple other places already.
b. I think inline functions help us keep the logic right where we need to make the decision (should we cleanup or not). The alternative would require us to send all the context, obj, logger and handle the errors differently and this feels a bit too much for the purpose.

[bnallapeta]

Just finished testing the fix manually with CAPD and it's working as expected!

Summary:

• Patched a KubeadmConfigTemplate to add a file
• Topology controller correctly created a new KubeadmConfig and updated the MachinePool.spec.template.spec.bootstrap.configRef
• Template rotation is now working for ClusterClass MachinePools

$ kubectl get kubeadmconfig -l cluster.x-k8s.io/cluster-name=test-cluster
NAME                       AGE
test-cluster-mp-0-2krrr    58m  # old config
test-cluster-mp-0-sw2m8    2m   # new config (rotated!)

$ kubectl get machinepool $MACHINEPOOL_NAME -o jsonpath='{.spec.template.spec.bootstrap.configRef.name}'
test-cluster-mp-0-sw2m8  # <-- reference updated correctly

Why CAPD?
Checked CAPA first but it's missing AWSMachinePoolTemplate (verified in their codebase). CAPD is currently the only provider with the template CRDs needed for ClusterClass MachinePools.

Next steps:
Moving on to E2E tests. Will look into how to add test coverage for this - any pointers on this is much appreciated!

(Detailed testing steps available if anyone wants to reproduce)