Feature Request: Prefer IPv6 dataLIF during auto-discovery on dual-stack SVMs #1173

Describe the solution you'd like

Add a way to prefer IPv6 data LIFs during auto-discovery in ValidateNASDriver
when no dataLIF is set in the TridentBackendConfig.

Currently (ontap_common.go, ValidateNASDriver), when config.DataLIF is
empty, Trident picks dataLIFs[0] — the first LIF returned by the ONTAP API
(ZAPI or REST). No orderBy parameter is passed in either code path, so the
list order is determined by the ONTAP API internally:

• ZAPI: returns LIFs in internal WAFL/RDB order (typically creation order,
  but not documented or guaranteed)
• REST: returns LIFs sorted alphabetically by LIF name by default

The result is non-deterministic from the user's perspective — it depends on
the ONTAP API type in use and the SVM LIF naming convention. On a dual-stack
SVM this frequently results in an IPv4 LIF being selected. There is no
IP-family preference logic anywhere in the selection path:

// ontap_common.go ~line 1953
// If they didn't set a LIF to use in the config, we'll set it to the first NFS/SMB LIF we happen to find
if config.DataLIF == "" {
    if network.IsIPv6Address(dataLIFs[0]) {
        config.DataLIF = "[" + dataLIFs[0] + "]"
    } else {
        config.DataLIF = dataLIFs[0]
    }
}

Environment

• Trident version: 26.02
• Backend driver: ontap-nas (same applies to ontap-san)
• ONTAP SVM: dual-stack — both IPv4 and IPv6 data LIFs configured
• Kubernetes cluster network: IPv6-only (nodes have no IPv4 connectivity to storage)

Use-case / Problem

In an IPv6-only Kubernetes cluster backed by a dual-stack ONTAP SVM (IPv4 LIFs
are needed for other consumers of the same SVM), Trident auto-selects an IPv4
dataLIF whenever it happens to be first in the ONTAP API response. NFS mounts
then fail because the nodes cannot reach the IPv4 address.

The existing IPv6: true / --use-ipv6 flag only affects Trident's own
internal REST API listener address and has no effect on dataLIF selection.

Explicitly hardcoding dataLIF to the IPv6 address is the only current
workaround. This is fragile in GitOps/multi-cluster setups:

• LIF IPs may change (SVM migration, DR failover)
• Requires a per-cluster static IP in Helm values, increasing operational burden

Describe the solution you'd like

One of the following, in order of preference:

1. A new backend config option preferIPv6DataLIF: true that makes Trident
   sort IPv6 addresses to the front of dataLIFs before picking [0].
2. Automatic detection: if managementLIF is an IPv6 address, prefer IPv6
   data LIFs automatically.
3. A dataLIFFamily: ipv4|ipv6|auto config field for explicit IP-family
   selection.

Describe alternatives you've considered

• Hardcoding dataLIF to the IPv6 address — works but operationally fragile (see above).
• Sorting LIFs ONTAP-side by naming convention — not reliable or portable across SVMs.

Additional context

Relevant code paths:

• storage_drivers/ontap/ontap_common.go — ValidateNASDriver (~line 1953)
• storage_drivers/ontap/api/ontap_zapi.go — NetInterfaceGetDataLIFs (line 3005)
• storage_drivers/ontap/api/ontap_rest.go — NetInterfaceGetDataLIFs (line 4046)

Both ZAPI and REST implementations pass no ordering parameter, leaving LIF
order entirely to the ONTAP API. The IsIPv6Address check on line 1954 only
handles bracket-formatting for IPv6 — it does not implement any preference
logic.