This PR enables faster NCCL RDMA upgrades, a subtle warning for gIB version changes, and integration of the gIB installer code into the kubectl-apply module.

Manually tested changes and a variety of scenarios using Terraform v1.11.4.

Faster NCCL RDMA installation

Previously, when the gIB NCCL plugin version was changed, the rolling update strategy used a maxUnavailable of 1 (the default value). This means that each node is updated one-by-one. With image pull times often exceeding 10 seconds, the rollout can leave large clusters in a broken, mixed-NCCL state for hours. Increasing the maxUnavailable to 16 reduces this rollout time by over an order of magnitude, while still maintaining the gradual/rolling update characteristics.

Subtle warning for gIB version changes

An environment with inconsistent NCCL versions can lead to tricky errors. As such, NCCL version changes need to be handled carefully. While the DaemonSet rollout and installer script should fully and cleanly update the environment when the installer image is upgraded, potential unmanaged NCCL environment variables/configurations and other "residuals" could cause issues. This is not so large a concern as to warrant deployment blocking, so a check block is added to give a warning when the gIB version changes. Like other check blocks in the repo, this warning is wedged between the terraform apply logs and the blueprint outputs after a gcluster deploy. I don't believe the warning needs more emphasis than this.

Integration of the gIB installer code

While largely a prerequisite for the previously-mentioned changes, I believe there's some value in this in it's own right. The integration of the gIB installer code into the kubectl-apply module seems like a cleaner and easier UX, while still fully allowing for the old approach of custom apply_manifests. The NCCL RDMA installer manifests across the a3-ultra and a4 blueprints are also identical, other than the gke-accelerator node affinity, so there's a bit of code deduplication value here.

There's strong precedent for this sort of shift in the kubectl-apply module already (Jobset, Kueue,. etc.).

Additional design notes

1. These changes do not affect default behavior of existing modules (gib.install is default false) or blueprints (apply_manifests works like it always has).
2. Loosening up the template_vars data type (kubectl-apply module) was required for the gIB NCCL installer integration, but I believe this is a sensible change in it's own right to enable more advanced templating on top of the manifests. Since the data typing was relaxed, rather than changed, this should not introduce any issues.
3. The default accelerator selector is set to the superset of all relevant accelerators (a3-ultra and a4) so that the setup still works if an accelerator_selector variable is not supplied. However, an accelerator_selector setting is explicitly provided in the a3-ultra and a4 blueprints for clarity.

Submission Checklist

• ✅ Fork your PR branch from the Toolkit "develop" branch (not main)
• ✅ Test all changes with pre-commit in a local branch #
• ✅ Confirm that "make tests" passes all tests
• ✅ Add or modify unit tests to cover code changes
• ✅ Ensure that unit test coverage remains above 80%
• ✅ Update all applicable documentation
• ✅ Follow Cluster Toolkit Contribution guidelines #