feat: [CLI-51461]: implementing checks to allow upgrade to ES v1 API

[harness-jc]

External Secrets has deprecated v1beta API. We need the capability to support older versions of ES but also migrate to V1 for future releases.

[CLAassistant]

All committers have signed the CLA.

[harness-jc]

File: src/common/templates/_eso-secrets-helper.tpl

Added API version detection:

{{- /* Detect which API version to use based on CRD availability */ -}}
{{- $useV1API := false }}
{{- if $.Capabilities.APIVersions.Has "external-secrets.io/v1/ExternalSecret" }}
  {{- $useV1API = true }}
{{- end }}
{{- if $useV1API }}
apiVersion: external-secrets.io/v1
{{- else }}
apiVersion: external-secrets.io/v1beta1
{{- end }}

File: src/common/templates/_dbv3.tpl

Fixed missing ctx parameter in function calls (lines 234, 514):
// Before
{{- include "harnesscommon.secrets.generateExternalSecret" (dict "secretsCtx" $localDBCtx.secrets "secretNamePrefix" $localDBESOSecretCtxIdentifier) }}

// After
{{- include "harnesscommon.secrets.generateExternalSecret" (dict "ctx" $ "secretsCtx" $localDBCtx.secrets "secretNamePrefix" $localDBESOSecretCtxIdentifier) }}

Why this fix was needed:
- The function signature always expected ctx parameter (per USAGE docs)
- Previous code had a dormant bug where ctx wasn't passed
- Didn't cause issues before because $ variable was never referenced
- Our new API detection logic requires $.Capabilities, making the fix necessary

How It Works

The template now automatically detects which ESO CRD version is available in the cluster:
1. Checks if external-secrets.io/v1/ExternalSecret CRD exists using Capabilities.APIVersions.Has
2. If available → uses apiVersion: external-secrets.io/v1
3. If not available → falls back to apiVersion: external-secrets.io/v1beta1

API Compatibility

Good news: The ExternalSecret spec structure is identical between v1beta1 and v1:
- ✅ Same secretStoreRef structure
- ✅ Same target.template structure
- ✅ Same data[].secretKey and remoteRef structure
- ⚠️ Only difference: engine field renamed to engineVersion (already updated)

Migration Path

Zero-downtime upgrade:
1. Current state: Charts generate v1beta1 resources (ESO < 0.17.0)
2. After this PR: Charts auto-detect and use v1 if available (ESO 0.16.2+)
3. After ESO upgrade to 0.17.0+: Charts automatically switch to v1
4. Result: No manual manifest updates needed ✨

Impact

Affected Components:
- All helm charts using harnesscommon.secrets.generateExternalSecret
- All charts with MongoDB or Redis using ESO secrets (via _dbv3.tpl)
- Static templates in harness-cluster-resources

Breaking Changes:
- ❌ None - backward compatible with ESO 0.16.2+
- ✅ Graceful fallback to v1beta1 for older versions
- ✅ Automatic upgrade path to v1

Testing Recommendations

Before merging:
- Verify templates render correctly on clusters with ESO 0.16.2 (should use v1)
- Verify templates render correctly on clusters with ESO < 0.17.0 (should use v1beta1)
- Test MongoDB/Redis chart deployments with ESO secrets enabled
- Validate ExternalSecret resources are created successfully

References

- https://github.com/external-secrets/external-secrets/releases/tag/v0.17.0 - v1beta1 removal
- https://external-secrets.io/latest/api/spec/

[ebn-harness]

LGTM

[arya-harness]

LGTM, can you also bump up the chart version