Potential overflow in probabilistic sampling

[isaachier]

See here: jaegertracing/jaeger-client-cpp#6. This should affect Go as well, not just C++.

[black-adder]

In go, we skirt around the problem by using const maxRandomNumber = ^(uint64(1) << 63), converting to float and back doesn't cause overflow. Seems like we do the same for all the other clients.

[black-adder]

https://play.golang.org/p/UUBenw5X15

So we do kinda "overflow" in that we go over max(int63), but logically it still works since we do:
s.samplingBoundary >= id.Low

[isaachier]

Maybe worth clarifying in a comment there.

// It relies on the fact that new trace IDs are 63bit random numbers themselves, thus making the sampling decision
// without generating a new random number, but simply calculating if traceID < (samplingRate * 2^63).
// TODO remove the error from this function for next major release

Not sure what the TODO is, but changing this in any way could break it. I'm wondering whether or not just to take @rnburn's advice to drop the boundary in favor of a new pseudo-random number here.