Can't handle 128 bit trace ids #49
Description
Having a hard time using this library effectively because the context propagation doesn't accept long enough traces, so any trace from upstream is being cut off when it reaches my node lambdas. So for example, I have the trace id c428a3427a392b88dde9cec77c6a57b7, and it's turning into 000000007c6a57b7, which must be the truncated 32 bit equivalent of my 128 bit original trace.
It looks like this is happening in the b3_text_map.js of this deprecated library that you guys are using under the hood, when it casts the trace id using traceId: new Uint64BE(traceId, 16). I opened it here, though, since I assume you're trying to move away from that library anyways.
As far as examples go, I cloned your repo locally, and verified that if I edited the test should inject properties of the active sync span in tracing-spec.js from 'X-B3-TraceId': generateId().toBuffer().toString('hex') to 'X-B3-TraceId': 'c428a3427a392b88dde9cec77c6a57b7', // 32 characters, 128 bits, you should be able to verify that these longer traces aren't being supported.
One other thing I'll call out is that it's other SignalFx libraries that I'm using that are generating this trace id. So the only upstream project I have is using this one and maybe the splunk-RUM stuff, and I've specifically set OTEL_PROPAGATORS=b3multi to make sure I'm using b3 headers there, so I'm surprised I can't get these two libraries to work together, and would love it if I could. Thanks!