[sdk-metrics] Obsolete SetMaxMetricPointsPerMetricStream + standarize on "Cardinality Limit" name

[CodeBlanch]

Follow-up to #5312

Changes

• Fixed a bug introduced by [sdk] Added support for setting CardinalityLimit allowed for the metric managed by the view. #5312 where a view specifying CardinalityLimit actually changes the value stored on the MetricReader which will then apply to any metrics recorded after the one which had the view apply: f1b62b0
• Obsolete MeterProviderBuilderExtensions.SetMaxMetricPointsPerMetricStream in favor of the View API added in [sdk] Added support for setting CardinalityLimit allowed for the metric managed by the view. #5312.
• Renames internal values to standardize on the "cardinality limit" name.
• Doc updates to no longer mention the global method.
• A bit of refactoring to how the settings get passed from MeterProvider to MetricReader.
• A bit of refactoring to remove the reflection in the new tests.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes

[reyang]

• Expose MeterProviderBuilderExtensions.SetCardinalityLimit experimental API (does the same thing as SetMaxMetricPointsPerMetricStream just with a name that will match the spec concept).

Do we want to expose this at all or we want to point folks to View level limit? Asking this because the spec doesn't ask for it https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#configuration-1

[CodeBlanch]

Do we want to expose this at all or we want to point folks to View level limit? Asking this because the spec doesn't ask for it

My thinking is we already exposed it with SetMaxMetricPointsPerMetricStream so we might as well name it something familiar/relatable/searchable to what the spec does have.

If you are thinking we should just do something like...

#if EXPOSE_EXPERIMENTAL_FEATURES
    [Obsolete("Use MetricStreamConfiguration.CardinalityLimit instead. This method will be removed in a future version.")]
#endif
    public static MeterProviderBuilder SetMaxMetricPointsPerMetricStream(this MeterProviderBuilder meterProviderBuilder, int maxMetricPointsPerMetricStream)

I'm also good with that.

[CodeBlanch]

I had an offline discussion with @reyang. We decided to obsolete SetMaxMetricPointsPerMetricStream and NOT add an alternative global mechanism. Because it isn't part of the spec and it may be too dangerous to have.

[Yun-Ting]

I feel .SetCardinalityLimit() is a bit confusing to use:

1. The current implementation of this method is setting a "global" value for the dimensions of each metric of a MeterProvider.
2. If user really cares about customizing each metric, they should be encouraged to leverage view to achieve that. And the view already has the API to set the cardinality limit.

[Yun-Ting]

CardinalityLimitofMatchingViewTakesPrecedenceOverMetricProviderWhenBothWereSet can be removed.
Can update to test this scenario instead: #5328 (comment)

[Yun-Ting]

LGTM!

[cijothomas]

Suggested change

	[Obsolete("Use MetricStreamConfiguration.CardinalityLimit via the AddView API instead. This method will be removed in a future version.")]
	[Obsolete("Use MetricStreamConfiguration.CardinalityLimit via the AddView API instead. This method will be removed in the next major version bump.")]

[cijothomas]

Or combine.. removed in a future version, along with major version bump of the package.

[CodeBlanch]

I'm not going to do this here because we use similar a bunch of places but good thing for a follow-up!

[cijothomas]

LGTM.
Left some comments on changelog/docs for better clarity for end users