Feature request: Authorize cross-namespace volume sharing using namespace labels #1196

Describe the solution you'd like

Currently, a source PVC authorizes cross-namespace volume sharing through
trident.netapp.io/shareToNamespace, which accepts namespace names or *.

We would like to allow source PVC owners to authorize sharing based on
destination namespace labels. This would simplify managing access when
namespaces are created and removed dynamically, while avoiding permission
to share with every namespace.

For example, a source PVC could use:

metadata:
  annotations:
    trident.netapp.io/shareToNamespaceSelector: "storage.example.com/share-group=ml"

A new shared PVC would be permitted only when its destination namespace
matches this Kubernetes label selector and has the required
TridentVolumeReference.

Proposed behavior:

• A selector alone can authorize sharing.
• When both a selector and a nonempty shareToNamespace value are configured,
  both conditions must match. * does not bypass the selector.
• When the selector annotation is absent, existing behavior is preserved.
• Empty or invalid selectors and namespace lookup failures reject provisioning.
• Destination namespace labels are retrieved when validating a new
  shared-volume configuration.

The initial scope is authorization of new shared-volume provisioning.
Removing a label required by a positive selector would deny subsequent
provisioning attempts. Existing shared volumes and mounted workloads would
continue to work. Previously admitted operations and idempotent requests
for already-created volumes would retain their existing behavior.

Continuous revocation of existing access and changes to cross-namespace
cloning are outside this initial scope.

Describe alternatives you've considered

• Maintaining explicit namespace lists on each source PVC requires updates
  whenever eligible namespaces change.
• Using shareToNamespace: "*" permits sharing more broadly than intended.
• An external controller could synchronize namespace labels into explicit
  namespace lists, but would require an additional component to operate.

Additional context

We searched existing issues and PRs and found related requests:

• Mandatory and explicit ownership of persistent volumes #1085 concerns shared-volume ownership and deletion behavior.
• Feature request: want to share the PVC between namespaces as read-only #935 concerns read-only cross-namespace sharing.

This proposal addresses namespace eligibility for new shared-volume
provisioning.

I intend to contribute a PR. A local prototype and unit tests have been
prepared, and I would like feedback from the Trident development team before
submitting it.

Would this annotation and authorization model be appropriate for Trident?
In particular, is requiring both conditions when the selector and namespace
list are configured the preferred behavior?