fix cks cluster stuck starting when a private registry is set

[Damans227]

Fixes #11596

With a private registry set, a new CKS cluster stays in Starting. The control node setup script for the registry is wrapped in {% if registry is defined %}, but registry is never a cloud-init variable. The server fills in the registry details as plain text, so the check is never true and the script is never written. The server still swaps the line that writes the containerd config for a call to that script, so containerd keeps its default config with the image service off and kubeadm never runs. This keeps the jinja header and changes the check to {% if "{{ registry.enabled }}" == "true" %}, and the server fills in true or false when it builds the user data.

Test:

• Added unit tests for a cluster with and without a registry. The lab run below was on the first commit.

• On a KVM lab with 2 hosts and cloud.kubernetes.cluster.experimental.features.enabled=true, create a CKS cluster (v1.36.0, 1 control node, 1 worker) with dockerregistryurl=https://index.docker.io/v1/ and a registry username and password.

Before: the cluster stays in Starting. On the control node:

bash: /opt/bin/setup-containerd: No such file or directory
disabled_plugins = ["cri"]
kubelet: open /var/lib/kubelet/config.yaml: no such file or directory

After: the cluster goes to Running and both nodes are Ready. On the control node:

$ ls /opt/bin | grep setup-containerd
setup-containerd
$ grep -E "disabled_plugins|index.docker.io" /etc/containerd/config.toml
disabled_plugins = []
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."index.docker.io/v1/"]
  endpoint = ["https://index.docker.io/v1/"]
$ kubectl get nodes
NAME                             STATUS   ROLES           AGE   VERSION
after11596-control-1a14050986c   Ready    control-plane   67s   v1.36.0
after11596-node-1a14050ede7      Ready    <none>          55s   v1.36.0

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 3.70%. Comparing base (d3f0700) to head (4d36ebe).

❗ There is a different number of reports uploaded between BASE (d3f0700) and HEAD (4d36ebe). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (d3f0700)	HEAD (4d36ebe)
unittests	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##               main   #14408       +/-   ##
=============================================
- Coverage     20.39%    3.70%   -16.70%     
=============================================
  Files          6481      493     -5988     
  Lines        588040    42544   -545496     
  Branches      72021     8065    -63956     
=============================================
- Hits         119957     1577   -118380     
+ Misses       455052    40741   -414311     
+ Partials      13031      226    -12805     

Flag	Coverage Δ
uitests	3.70% <ø> (ø)
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Pearl1594]

code lgtm - havent tested this.