rw2: add stateless and stateless-typed modes (rc.6)

[bwplotka]

Alternative to #3129.

Specify two progressive modes (stateless and stateless-typed) for io.prometheus.write.v2.Request in Remote-Write 2.0-rc.6, following the Prometheus Dev Summit consensus and RFC 9413.

By default, when no ;mode= parameter is set on Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request, all field permutations permitted by the base specification may be sent. 2.0-rc.6 adds two optional, progressive modes where senders MUST guarantee (and receivers CAN expect):

1. stateless mode (Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request;mode=stateless):
   • Exemplars are attached to a TimeSeries that contains at least one sample or histogram (no exemplar-only TimeSeries).
   • Histograms use the Histogram message (classic histograms must be sent as NHCB instead of _bucket, _sum, and _count float series).
2. stateless-typed mode (Content-Type: application/x-protobuf;proto=io.prometheus.write.v2.Request;mode=stateless-typed):
   • All requirements of stateless mode.
   • Metadata.type is set (not METRIC_TYPE_UNSPECIFIED).
   • start_timestamp is set (non-zero) on every sample and histogram for cumulative and delta metric types (METRIC_TYPE_COUNTER, METRIC_TYPE_HISTOGRAM, and METRIC_TYPE_SUMMARY _sum and _count).

Both modes are optional for senders and receivers and remain valid io.prometheus.write.v2.Request payloads on the wire.

Receiver acceptance and violation rules

• Two-way negotiation contract: Receivers that support a given mode MUST NOT reject TimeSeries for omitting fields only required by a stricter mode (for example, a Receiver accepting mode=stateless must accept series with METRIC_TYPE_UNSPECIFIED or start_timestamp = 0; if it requires those fields, it must require mode=stateless-typed and return 415 HTTP Unsupported Media Type for lower modes).
• Mode violations (400 HTTP Bad Request): If a request violates the mode specified in its Content-Type header, Receivers MUST treat the violating TimeSeries as invalid samples and return 400 HTTP Bad Request (either rejecting the entire request or writing the valid TimeSeries following partial write rules).

Why two progressive modes instead of one mode or separate capabilities?

1. Sender formatting vs. upstream instrumentation boundary:

   • The stateless rules (attaching exemplars to samples/histograms and converting classic histograms to NHCB) are pure sender-side formatting choices. Any sender (such as Prometheus or Alloy) can enforce them by configuration alone without dropping data, even when scraping legacy targets.
   • The stateless-typed rules (Metadata.type and start_timestamp) require every series to have a known metric type and counter start time. When scraping targets that expose untyped metrics or omit _created timestamps, a sender can only satisfy stateless-typed by synthesizing state, inferring types, or dropping non-conforming series.
   • Splitting them allows universal adoption of stateless mode while giving strict OpenTelemetry/typed receivers (stateless-typed) the full contract they need.

2. Why stateless-typed includes stateless (keeping mode= instead of capabilities=):

   • Validating start_timestamp already requires knowing Metadata.type, and receivers that require explicit metric types and start timestamps also require structured histograms and attached exemplars.
   • Progressive modes (default < stateless < stateless-typed) give 3 well-defined protocol states rather than $2^N$ capability combinations (RFC 9413), keep Content-Type matching to a single parameter value, and keep prometheus/compliance testing linear.

[ENHANCEMENT] Remote-Write 2.0: Add optional `stateless` and `stateless-typed` modes (`rc.6`).