[sdk-metrics] Promote cardinality limit view API from experimental to stable

[xiang17]

Fixes #5444.

Changes

Promote cardinality limit view API from experimental to stable. Updates README and obsolete flags for MeterProviderBuilder.SetMaxMetricPointsPerMetricStream to note that they are in stable.

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
• Changes in public API reviewed (if applicable): The APIs were in src\OpenTelemetry\.publicApi\Experimental\PublicAPI.Unshipped.txt.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.02%. Comparing base (6250307) to head (53ed5af).
Report is 361 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5926      +/-   ##
==========================================
+ Coverage   83.38%   86.02%   +2.64%     
==========================================
  Files         297      260      -37     
  Lines       12531    11437    -1094     
==========================================
- Hits        10449     9839     -610     
+ Misses       2082     1598     -484     

Flag	Coverage Δ
unittests	?
unittests-Project-Experimental	85.95% <ø> (?)
unittests-Project-Stable	86.00% <ø> (?)
unittests-Solution	85.95% <ø> (?)
unittests-UnstableCoreLibraries-Experimental	84.36% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
.../Metrics/Builder/MeterProviderBuilderExtensions.cs	98.42% <ø> (-1.58%)	⬇️
...elemetry/Metrics/View/MetricStreamConfiguration.cs	88.88% <ø> (ø)

... and 237 files with indirect coverage changes

[reyang]

Does this need to be moved?

[xiang17]

I was simply following the convention of the OTEL1002 above which was released and moved from "Active" to "Inactive". Personally I think it'd also be helpful to have a record of what happened to previous experimental features.

[reyang]

will be -> is?

[reyang]

I wonder how folks think about https://www.theregister.com/2024/10/08/linus_torvalds_grammar_complaint/?

[xiang17]

This wording is also used in other experimental APIs in this CHANGELOG.

[cijothomas]

I think "is" is better. Would be good to follow up and make changes everywhere. Not a blocker for this.

[xiang17]

Created a PR #5940 for this.

[reyang]

Left couple suggestions/questions that are non-blocking.