feat: add nameOverride support to helm templates

[slntopp]

Description

When using Tetragon as a Helm dependency, all resources are named after the release name, causing:

• Naming conflicts with parent application resources
• Confusion when managing multiple releases
• Resources appearing at the same level as the parent app instead of clearly being dependencies

Solution

Added tetragon.nameOverride and tetragonOperator.nameOverride fields to allow explicit control over resource naming independent of the Helm release name.

Benefits:

• Prevents resource naming conflicts
• Clearer separation between app and dependency resources
• Better operational visibility in complex deployments
• Follows standard Helm naming patterns

Example usage:

tetragon:
  nameOverride: "security-agent"
tetragonOperator:
  nameOverride: "security-operator"

This maintains backward compatibility (defaults to release name when empty) while solving the dependency naming pain point.

Changelog

• adds nameOverride to tetragon and tetragonOperator Helm values.
• adds helper templates and makes resources names dependent on tetragon and operator names

helm: add `tetragon.nameOverride` and `tetragonOperator.nameOverride`

[netlify]

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	5f79a22
🔍 Latest deploy log	https://app.netlify.com/projects/tetragon/deploys/6878e777f72a4c0008b87fe7
😎 Deploy Preview	https://deploy-preview-3864--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mtardy]

Hey just fyi we have a draft PR opened for that #3604 which seems a bit abandoned. Will review this one thanks! :)

[michi-covalent]

looks great 🥰

[kkourt]

Why is trimSuffix needed here?

[slntopp]

Most k8s object names and ids must start and end with alphanumeric chars, this is common failsafe.

You could theoretically set your release name or nameOverride to amazing-tetragon-deployment-named-long-with-dashes-because-why-not (66 chars), truncated to 63 would result into amazing-tetragon-deployment-named-long-with-dashes-because-why-, which would fail

[mtardy]

Overall looks good! Should you also update the remaining app.kubernetes.io/instance: {{ .Release.Name }} labels around?

[slntopp]

Best practice is for app.kubernetes.io/instance to be the same across all workloads deployed under the same release, so you can do things like kubectl get all -l app.kubernetes.io/instance=my-release

[mtardy]

All right thanks for the answers, let's merge this :)