OM 2.0: Limit length of exemplars in bytes, not runes

[beorn7]

Problem Statement

This has been discussed before: #198

I still believe it was a mistake to set a rune limit for exemplars in v1.

Recent user request: prometheus/client_golang#1803

Proposed solution

See #198
prometheus/client_golang#1803 (comment)

Alternatives considered

To quote my former chancellor: "Alternativlos"

[tcolgate]

It is worth noting that, as of the time of writing, the opentelemetry client's prometheus exporter does not attempt to enforce the rune limit (despite their spec), and allows oversized exemplars to fall through to the underlying prometheus client, which then fails the metric observation. That is unquestionably a bug in that code, according their own spec, but gives an indication of the real world problems caused by this.
The existing size limit means there's is little space for labels beyond trace and span IDs.

[dashpole]

Discussed during OM 2.0 triage. We do want to include this in the 2.0. This is also inconsistent with other protocols (e.g. PRW 2.0) which do not impose exemplar size limits.

We need to decide between:

1. Remove exemplar size limits from the spec entirely, and leave it to the server (e.g. exemplar_size_limit to impose limits on the size of exemplars when scraping, similar to other limits.
2. Change to a bytes limit, and make it larger (e.g. 512bytes) so that it isn't as much of an issue in practice.

We plan to propose removing exemplar size limits from OM 2.0

[bwplotka]

From WG: Skipping this for RC.0 for now.

[bwplotka]

Idea: Remove the limit