Mark cardinality limits as Stable

[reyang]

Mark cardinality limits as Stable.

Fixes #3904

These are the language implementations:

• .NET https://github.com/open-telemetry/opentelemetry-dotnet/blob/60b7d9baf32ee437ba3e84f1886ba8917e8d9475/src/OpenTelemetry/Metrics/AggregatorStore.cs#L457
• Go https://github.com/open-telemetry/opentelemetry-go/blob/6731dc70900c4e5e47e00eb0340865189a5d1a76/sdk/metric/internal/x/README.md?plain=1#L14 and https://github.com/open-telemetry/opentelemetry-go/blob/6731dc70900c4e5e47e00eb0340865189a5d1a76/sdk/metric/internal/aggregate/limit.go#L11
• Java https://github.com/open-telemetry/opentelemetry-java/blob/fa826fdef07167b22089b96b957749e9f41e72e2/sdk/metrics/src/main/java/io/opentelemetry/sdk/metrics/internal/state/MetricStorage.java#L27
• Rust https://github.com/open-telemetry/opentelemetry-rust/blob/d652dc82fcb828909877c3492f85d3a8206efd6e/opentelemetry-sdk/src/metrics/mod.rs#L2017

Changes

Please provide a brief description of the changes here.

For non-trivial changes, follow the change proposal process.

• Related issues
  • Split collection limit out of cardinality limit #3813 There was a Technical Committee meeting on Sep. 25th, we don't think this is a blocking issue. @MrAlias raised it up and I'm clarifying with him whether it is a blocker. Mark cardinality limits as Stable #4222 (comment)
  • Metric cardinality limits "overflow attribute set" causes inconsistent attribute keys #3578
  • How is the cardinality limit applied when attributes are being filtered? #3798
  • Clarify metric stream, point and cardinality limit #3866 (the blocking part has been addressed by [Editorial] clarify cardinality limit #3856 and Clarify metric point #3906, the issue will remain open to track the other parts and those are not blocking the stabilization)
• Related OTEP(s) #
• Links to the prototypes (when adding or changing features)
• CHANGELOG.md file updated for non-trivial changes
• spec-compliance-matrix.md updated if necessary

[cijothomas]

There are few issues that were raised earlier on this topic. We should mark them as resolved (and close the issue), or mark them as non-blocking for stability for cardinality limits.
#3904 (comment)

Per #4222 (comment)

[reyang]

... or mark them as non-blocking for stability for cardinality limits

How do you want to mark them as non-blocking? @cijothomas

[MrAlias]

I feel this issue needs a resolution before this can become stable.

[cijothomas]

... or mark them as non-blocking for stability for cardinality limits

How do you want to mark them as non-blocking? @cijothomas

TC can leave a comment on the issues saying "it is not a blocker for stabilizing cardinality limits feature spec".
(I don't think it worth creating github labels like blocking-cardinality-stable, allowed-cardinality-stable, nice-to-have-cardinality-stable etc, so a simple comment can help.)

[reyang]

I feel this issue needs a resolution before this can become stable.

@MrAlias Is this something that cannot be an additive change later, and must be resolved now? Would you help to clarify? Thanks!

[jmacd]

@reyang My opinion is that #3813 should not be a blocker. We are trying to impose a limit on the SDK without specifying the exact mechanism that it uses, because SDKs will take different and reasonable approaches to aggregation, and all that matters is that they reach a limit and respect it. How the limit is reached and respected is an implementation detail, and when the limit is reached the telemetry coming from an application is degraded, that is all that I expect from cardinality limits.

[cijothomas]

LGTM. The listed issues are non-blocking in my opinion, so we can proceed with stabilizing.