[6to7] Add support for 128-bit TraceId

[PerfectSlayer]

What Does This Do

This PR introduces the support for 128-bit TraceId.
A flag was introduced trace.128.bit.traceid.generation.enabled to generate 64-bit or 128-bit TraceIds.

Motivation

Provide better interoperability with external tracing systems.

Additional Notes

I will keep iterating on the DDTraceId API to get it smaller and cleaner as possible.
I think I can also improve cached string for ID, caching only padded representation (B3 has TraceIdWithOriginal implementation that can help with its custom format cache).

Two others issues will be filled about:

• Improving support for Haystack 128-bit TraceId,
• How should we handle XRay 128-bit TraceId and its timestamp (like: can we use or own format to map the e2e start time?)

And another PR is dedicated to bring 128-bit TraceId logging support: #4938

[bantonsson]

Great work. Left some comments and ramblings. I'll get around to looking at the propagation next.

[odin-delrio]

I'm quite sure I'm missing something here... but I'm really curious and I want to understand it, why you create an additional variable there instead of just operating with the class property? something like:

  @Override
  public String toString() {
    if (this.str == null) {
      this.str = Long.toUnsignedString(this.lowOrderBits);
    }
    return this.str;
  }

[bantonsson]

Hey @odin-delrio, as the author of the original code in DDTraceId I can say that it's about helping the compiler. The javac compiler is rather dumb in the respect that it will do exactly what you tell it.
In the code in this PR, there will be one read from the str field, and one store to the str field (if it was null), while the code you proposed will have two reads from the str field no matter what (and of course one store if it was null). Local variables are free compared to objects and field access.
Yes, this will be optimized away by the JIT eventually, but being mindful of the cost of field access and method calls is ingrained in my way of thinking.

[odin-delrio]

hey @bantonsson, thanks a lot for the detailed explanation ❤️!!! (I was not even sure if I would get a response to a random question like this, but I was reading the code and my curiosity made me raise the question).

I didn't know that reading from a field implied a higher cost than reading from a local variable, now it makes sense to me.

[LeifW]

How are we supposed to get these 128-bit TraceIds back out? The toTraceId() on OTSpanContext calls .toString() on the DDTraceId, which the Javadoc for says "Returns a 64-bit only decimal String representation of the DDTraceId".
That is - how do we get the original 128-bit hexadecimal TraceId?