Add flag to disable high-cardinality metrics

[aliaqel-stripe]

Provide a description of what has been changed

This adds --enable-high-cardinality-metrics to the KEDA operator and metrics adapter, defaulting to true.

When the flag is disabled, KEDA suppresses the current high-cardinality histogram metrics while keeping the related counters enabled. This change also adds unit and e2e coverage for the disabled path and updates the changelog.

The e2e coverage was also hardened so the new flag assertions are reliable:

• deployment arg mutations now wait for a full rollout, so the tests do not assert against old operator or metrics adapter pods after toggling the flag
• the OpenTelemetry disabled-path assertion now runs before the Prometheus HTTP-client scenarios, so the collector does not already contain the histogram family from earlier requests
• the OpenTelemetry scaler error assertion now waits for the collector export instead of relying on a fixed sleep

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #7731

Relates to kedacore/keda-docs#1772, kedacore/charts#855

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[semgrep-code-kedacore]

Semgrep identified an issue in your code:
Consider to use well-defined context

To resolve this comment:

🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by context-todo.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-kedacore]

Semgrep identified an issue in your code:
Consider to use well-defined context

To resolve this comment:

🔧 No guidance has been designated for this issue. Fix according to your organization's approved methods.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by context-todo.

_{You can view more details about this finding in the Semgrep AppSec Platform.}