Investigate feasibility of zero-allocation protobuf marshalers

[jack-berg]

The OTLP protobuf marshalers maintain a bunch of state as they transform SpanData, MetricData, LogRecordData to an intermediate representation before serializing. We should investigate whether we can eliminate this state to produce zero allocation marshalers.

Discussed in #5105 and in discussion #5724.

[asafm]

Protocol Buffers forces you to know the size of an embedded message before you write its binary encoding.
This means you must:

1. Encode the embedded message to a temporary buffer
2. Grab the length of the buffer
3. Write the size of the buffer
4. Write the buffer (encoding of the message).

The intermediate classes' primary goal (i.e., Marshaler*) is to contain the size for each. Another goal is mapping the protobuf schema since the schema and the MetricData are not entirely 1:1 mapping.

I spent two days and had yet to do the serialization in a streaming fashion; hence, the only way out I saw was the reusable objects and object pooling. A very rough idea is at #6171.

[jack-berg]

Completed in the following PRs:

• Low allocation OTLP logs marshaler #6429
• Low allocation OTLP metrics marshaler #6422
• Marshal span status description without allocation #6423
• Low allocation OTLP trace marshaler #6410
• Add memory mode support to OTLP exporters #6430