SDK 2.0 OTLP exporters

[dyladan]

The 2.x line will require an exporter for each signal for testing during development. We will select 1 OTLP exporter per stable signal and copy them into the 2.x line. The exporters will continue to target the same SDK version as the other experimental packages. If the OTLP exporters are stabilized during the 2.x development, they will be released as 1.x and moved into the 2.x line at that time.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[MSNev]

As part of the Event WG there is a side discussion occurring around potentially creating 1 or more different supported export formats. open-telemetry/semantic-conventions#505 (comment)

As part of any optimization (changing the internal representation to closer/exactly match the serialized out) then any refactoring around defining the internal representation should consider that the internal representation (may) need to be different to support any configured exporter.

eg.

• If a ProtoBuf exporter is used then we have the protobuf internal representation
• If a web optimized (JSON) exporter is used then we have a different internal representation

Potentially, using a combination of Proxy, get/set to hide differences, with the usage of the internal types all defined and using interfaces and the user can configure the concrete types (somehow).