[doc] Improve wording regarding to overflow attribute once cardinality limit is reached for easier understanding for end-users

[xiang17]

Package

OpenTelemetry

Is your feature request related to a problem?

According to the spec https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#overflow-attribute, once cardinality limit is reached, the measurements could not be "independently aggregated", but it's not called "dropped". What happens is a "synthetic aggregation":

An overflow attribute set is defined, containing a single attribute otel.metric.overflow having (boolean) value true, which is used to report a synthetic aggregation of the Measurements that could not be independently aggregated because of the limit.

This can be confusing to end-users.

I'm opening this issue to track @cijothomas' suggestion for improvement at #5909 (comment):

Agree that the wording may not easily be understood by all end-users. The https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics#cardinality-limits doc is very good, and perhaps we can make some additions to it to explain how the sdk behaves when limit is hit, and how to interpret overflow attribute correctly.

One important think I'd like called out is, if user has a query like sum of all requests, where route=foo, and an overflow exists - then that query is no longer trustable, as there is no way to tell if a route=foo measurement was folded into overflow. The only thing trustable in the event an overflow exists is the total metrics (i.e the one which do not filter based on any dimensions).

If none volunteers to make this change in the doc, I can cover it. (I am implementing similar thing for OTel Rust right now, so I can hopefully steal some wordings! Ideally this should be covered in otel docs website, so every language can benefit) https://github.com/utpilla/MetricOverflowAttribute?tab=readme-ov-file can be a good starting point.

What is the expected behavior?

N/A

Which alternative solutions or features have you considered?

N/A

Additional context

No response