Support chart-wide commonLabels/extraLabels on all resources, and set app.kubernetes.io/version

[khateeb15]

Is your feature request related to a problem? Please describe.

Many organisations require a standard set of labels on every Kubernetes resource, for cost allocation, ownership/asset tracking, and policy enforcement (OPA/Kyverno rules that reject unlabelled resources). Today the chart makes this impossible without post-rendering or forking:

• extraLabels is only supported on a handful of resources: server.extraLabels, injector.extraLabels, server.serviceAccount.extraLabels, csi.daemonSet.extraLabels, csi.pod.extraLabels, and csi.serviceAccount.extraLabels.
• Even where supported, coverage is partial: server.extraLabels is applied only to the pod template, not to the StatefulSet's own metadata.labels (server.extraLabels missing on statefulset #911, Ability to have top level label on StatefullSet #992).
• All other resources; Services, ConfigMaps, Ingress/Route/HTTPRoute, RBAC objects, the MutatingWebhookConfiguration, PodDisruptionBudgets, NetworkPolicies, Secrets, PSPs, ServiceMonitor/PrometheusRule, accept no custom labels at all.
• The chart never sets app.kubernetes.io/version, despite it being one of the Kubernetes recommended labels, and the standard labels it does set are applied inconsistently across templates (see fix: add missing helm.sh/chart labels #1183 for missing helm.sh/chart labels).

There is a long tail of open issues and PRs each attacking one slice of this problem (see "Additional context"), but no chart-wide solution.

Describe the solution you'd like

1. A single chart-wide values entry e.g. global.extraLabels (or commonLabels) merged into metadata.labels of every resource the chart renders, including pod templates. This is a well-established pattern in other popular charts (kube-prometheus-stack commonLabels, ingress-nginx commonLabels, Bitnami's commonLabels, cert-manager global.commonLabels).
2. Set app.kubernetes.io/version: {{ .Chart.AppVersion }} as part of the standard labels on all resources.

To keep upgrades safe, the common labels should be added to metadata.labels and pod template labels only, not to spec.selector/matchLabels, which are immutable on existing StatefulSets/Deployments.

Existing per-resource extraLabels values would keep working as more specific overrides, so the change is fully backwards-compatible.

Describe alternatives you've considered

• Post-rendering with Kustomize: works, but pushes complexity onto every consumer of the chart and breaks the plain helm install/upgrade workflow.
• Per-resource extraLabels additions: this is what the existing open PRs do (Add server.extraLabels to the StatefulSet metadata in addition to its Pods #505, Add labels to deployment, statefulset, service accounts and volumeClaimTemplates #680, feat: Support extraLabels in Service #1176), but piecemeal coverage has left gaps for years and several of those PRs have gone stale.
• Maintaining a fork: our current workaround, but obviously undesirable for everyone.

Additional context

Related open issues:

• server.extraLabels missing on statefulset #911:server.extraLabels applies only to pods, not StatefulSet metadata
• Ability to have top level label on StatefullSet #992: ability to set top-level labels on the StatefulSet (near-duplicate of server.extraLabels missing on statefulset #911)
• Stardardization of naming conventions for labels and resource names #265: standardisation of label naming conventions

Related open PRs:

• Add server.extraLabels to the StatefulSet metadata in addition to its Pods #505: adds server.extraLabels to StatefulSet metadata (open since ~2021)
• Add labels to deployment, statefulset, service accounts and volumeClaimTemplates #680: labels for Deployment, StatefulSet, ServiceAccounts, volumeClaimTemplates
  (revival of Add labels to deployment, statefulset and service accounts #478, now stale with conflicts)
• feat: Support extraLabels in Service #1176: extraLabels for Service resources only
• fix: add missing helm.sh/chart labels #1183: fixes missing helm.sh/chart labels on some resources

A chart-wide mechanism would resolve #911, #992, and supersede #505, #680, and #1176 in one consistent change rather than several partial ones.

I'm happy to contribute the PR for this (wip)