Use buffer instead string for traceId and spanId

[Flarna]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

The fields traceId and spanId in SpanContext are of type string formatted as hex. This requires several conversions:

• a buffer to string conversion during creation
• a string to buffer conversion during exporting (at least if opentelemetry protocol is used)
• a string to buffer conversion during propagation in binary format

I think it would be more efficient to avoid most of these conversions by keeping the buffer and convert to string only for logging/propagation as string.

Or is there a special reason for using a string?

Another option would be to hide this at all in a dedicated TraceId/SpanId class like e.g. in Java which would allow to hide the actual creation/storage at all and enable caching of different representations.

[vmarchaud]

I'nm not in favor of adding a dedicated class/interfaces for that because i feel it had much complexity that isnt needed there, i would prefer a consensus on one way to create/store those values. Buffer are fine for me.

[draffensperger]

If we go this route, we should use ArrayBuffer for browser compatibility, and it does have decent browser support (see MDN ArrayBuffer docs).

Have you thought about the need to serialize / deserialize these in trace headers for HTTP? I guess I'm not totally convinced that all use cases would benefit from our in-memory representation being an ArrayBuffer.

[Flarna]

Serialization of trace headers happens only on process entry/exit. Some protcols may need the buffer representation not string like HTTP - maybe to get a more compact/efficient result.

Each process entry/exit is also represented by a Span which usually needs to be exported.
Therefore for HTTP spans with a TraceTag string and binary representation is needed always.
But for internal spans or spans without tags (e.g. database) we need string for in memory representation and binary for export.

[Flarna]

see #786