Update Helm configuration after installation

Update nodePoolCIDR after the driver is already installed

1. Update the value via a Helm upgrade, keeping every other existing value unchanged. For a single CIDR, --set is fine:
   helm upgrade <release-name> <chart> -n <namespace> --reuse-values --set default.nodePoolCIDR="10.39.194.0/24"
   For multiple CIDRs, either escape the comma or - simpler - set it in a values file instead (see the Data Control Tower Connectivity parameter table)
   helm upgrade <release-name> <chart> -n <namespace> --reuse-values --set default.nodePoolCIDR="10.39.194.0/24\,10.39.200.0/24"

2. Restart the node DaemonSet. The Helm upgrade only updates the ConfigMap; the running node-plugin pods read nodePoolCIDR into an environment variable once at process start, which is not live-reloaded, so without this step they silently keep running on the old value indefinitely: kubectl -n <namespace> rollout restart ds/csi-de-node
   Follow with kubectl -n <namespace> rollout status ds/csi-de-node to confirm the restart actually completed before relying on the new value. Only the node DaemonSet needs this - the controller pod does not use nodePoolCIDR at all.

3. Note for administrators: existing NFS address entries on VDBs that are not remounted are not proactively rewritten - the new value only takes effect the next time a mount actually happens against a given VDB's Delphix environment (e.g. a pod reschedule or a new VDB), and only once step 2 above has completed. A VDB whose pod keeps running on its current node is unaffected and keeps working correctly on its existing whitelist entry; it simply won't pick up the new CIDR-based entry until its next mount.

Update default.nfsVersion after the driver is already installed

1. Update the value via a Helm upgrade, keeping every other existing value unchanged: helm upgrade <release-name> <chart> -n <namespace> --reuse-values --set default.nfsVersion="4"

2. Unlike default.nodePoolCIDR, no DaemonSet restart is needed - default.nfsVersion is not read by the running driver process, it only changes what Helm renders into the de-fs-storage StorageClass's mountOptions, which the Kubernetes CSI provisioner reads fresh at each new volume's creation time.

3. Note for administrators: existing PVs are not retroactively changed - the new value only takes effect for VDBs provisioned after the Helm upgrade completes. A VDB provisioned before the change keeps mounting with whatever options were baked into its PV at creation time.