Reduce generated Span ID range to fit in Fixnum

[marcotc]

Ruby transparently handles small and large integers using the Integer object. Behind the scenes, a number could either be a Fixnum or Bignum.

A Fixnum "Holds Integer values that can be represented in a native machine word (minus 1 bit)", and thus requiring no auxiliary memory to be represented.
Fixnums are faster to create and manipulate.

The transparent boundary between Fixnums and Bignums, in the positive integer range, is around 2**62:

require 'objspace'
ObjectSpace.memsize_of(2**62-1)
# => 0
ObjectSpace.memsize_of(2**62)
# => 40

In the tracer, we were generating random span ids up to 2**63, meaning half the generated ids were internally Bignums.

This PR reduces the range of internally generated span ids** to up to 2**62-1. The limit of this new range is still sufficient to produce unique ids for the purpose of tracing.

This does not affect spans received from external sources: those are still handled as-is, without modification.

Also, this PR fixes our sampling logic that performs Knuth's sampling algorithm to use the correct maximum range: before we were using 2**63, but our specs require our sampling to be consistent across languages, specially when possibly handling externally provided span ids. The specs require 2**64 to be the sampling range limit. This fix can be seen in "Datadog::RateSampler#sample?".

Benchmark results

For our critical path benchmark, that measures span creation up until the hand-off to the background worker:

• 1-6% wall time reduction
• 4-6% memory reduction
• 11-22% fewer objects created

Before [operations/sec]
     1 spans:   41298.16
    10 spans:    9982.20
   100 spans:    1239.96

After [operations/sec]
     1 spans:   41898.30
    10 spans:   10466.44
   100 spans:    1322.01

Comparison (% faster; slower if negative)
     1 spans:       1.45
    10 spans:       4.85
   100 spans:       6.62

Before [bytes allocated (objects created)]
     1 traces:   251760.00 (   2784.00)
    10 traces:  1825600.00 (  14464.00)
   100 traces: 17502136.00 ( 131539.00)

After  [bytes allocated (objects created)]
     1 traces:   239400.00 (   2475.00)
    10 traces:  1705920.00 (  11472.00)
   100 traces: 16299616.00 ( 101476.00)

Comparison (% reduction, increase negative)
     1 traces:       4.91 (     11.10)
    10 traces:       6.56 (     20.69)
   100 traces:       6.87 (     22.85)

[brettlangdon]

11-22% fewer objects created

What perceived impact does this have on an application?

[richardstartin]

Whilst I can't dispute the local benefits, I'm not sure this a good idea because it makes it twice as likely that there will be a span ID collision with other applications in the trace, which might be node, Java, .NET, etc.

[ericmustin]

the implementation itself lgtm so happy to approve, but i will defer to other folks on whether we want to introduce this change due to potential conflicts with other languages as mentioned by other reviewers.

[raphaelgavache]

The increased probability of spanID collision in a single trace is acceptable, lgtm