feat: gate all templates on storage-foundation not being enabled

[duckhawk]

Description

Wrap every Helm template under templates/ with

{{- if not (.Values.global.enabledModules | has "storage-foundation") }}
... existing body ...
{{- end }}

so the chart renders zero manifests as soon as the storage-foundation module is enabled in global.enabledModules. Templates that contain {{- define ... }} helpers (templates/snapshot-controller/deployment.yaml and templates/webhooks/deployment.yaml) keep the define block outside the gate, so the helper stays available regardless of whether the body is rendered.

No manifest content was changed — only the surrounding {{- if … }} … {{- end }} was added. When storage-foundation is not in global.enabledModules, the chart renders byte-for-byte the same output as before; when it is, helm template produces an empty result. Both cases were verified locally with helm template against this branch.

Why do we need it, and what problem does it solve?

We are migrating users from the snapshot-controller module to storage-foundation. The new module ships its own copies of the snapshot-controller Deployment, the webhooks Deployment / Service / MutatingWebhookConfiguration, the registry secret, the namespace and all RBAC. Without a hand-off mechanism, enabling storage-foundation while snapshot-controller is still on means:

• two snapshot-controller Deployments (in d8-snapshot-controller and d8-storage-foundation) competing for the same VolumeSnapshot* objects via separate leader-election leases;
• two MutatingWebhookConfigurations mutating every VolumeSnapshot CREATE;
• clashing ClusterRole/ClusterRoleBinding names (d8:snapshot-controller:admin-kubeconfig, d8:user-authz:snapshot-controller:*, d8:manage:permission:module:snapshot-controller:*, d8:use:capability:module:snapshot-controller:*, d8:snapshot-controller:snapshot-controller:runner/:rbac-proxy) — these names are owned by this module, not by storage-foundation, so they wouldn't collide between releases, but they would also keep granting access to a controller that is no longer authoritative.

The companion PR deckhouse/storage-foundation#21 brings the missing RBAC, CRDs, doc-ru and the remove-finalizers-on-module-delete hook into storage-foundation, so it is safe to let it take over.

This PR is the operator-facing piece of the migration: it lets an admin enable storage-foundation first and only then disable snapshot-controller, instead of having to do both at the exact same deckhouse reconciliation tick.

What is the expected result?

• When storage-foundation is not in .Values.global.enabledModules, helm template of this chart produces the same set of manifests as before this PR (verified for the RBAC files explicitly; smoke-rendered for the rest).
• When storage-foundation is in .Values.global.enabledModules, helm template of this chart emits no manifests at all — verified locally:
  • the snapshot-controller Deployment, PodDisruptionBudget, VerticalPodAutoscaler, PodMonitor and ServiceAccount are not rendered;
  • the webhooks Deployment, Service, Secret, MutatingWebhookConfiguration, ServiceAccount, ClusterRole and ClusterRoleBinding are not rendered;
  • the namespace d8-snapshot-controller, the registry secrets, all RBAC roles and the user-authz / rbacv2 cluster roles are not rendered.
• Existing clusters that do not enable storage-foundation see no behavioural change.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.