Improve offset calcuation and application when normalizing to SDK clock

[bidetofevil]

Goal

We should do a better job of normalizing a timestamp produced by OkHttp to fit the SDK clock baseline. Currently, we can potentially erroneously introduce a small difference simply because one clock reading comes after the other, and even though the difference should only be in the order of a handful of microseconds, the result when rounding to milliseconds means we could "tick over" the boundary even if there was no difference at all.

There are different approaches to doing the conversion, but since they all involve taking two clock readings, any naive way of doing it will have the issue we have now. The way I've chosen isn't perfect, but it should get the primary job done: eliminate the erroneous "tick over" if there's no actual difference at all. It will probably mean that sub-millisecond offsets will be ignored, but I think that level of precision is less of a problem, so the trade off is worth it.

Basically, we take two diff readings, and ensure that their absolute difference is less than or equal to one. Normally, there shouldn't be any differences, so we return their sum divided by 2, which should just be the same as either reading. If the difference is 1ms, it means it's most likely that one of the readings has a "tick over". If the difference is greater than 1, it means either the clock was changed in the time where these readings were being made, or if it takes more than a millisecond to longer between one reading than other, which would put us in a state where we don't know which to trust. In that case, we simply return 0 for the offset.

So for example, if the reading for one is 0 and the other is 1, taking the sum and dividing by 2 gets us 0 due of how division of longs work, thus eliminating the erroneous offset. If one is 100 and the other is 101, we'll return 100, conservatively assuming the larger value is due to tick over even though it could be the other way around. if one is 100 and the other is 150, something odd or incredibly rare is happening, so we'll just not return an offset.

Testing

Added unit tests

[bidetofevil]

Current dependencies on/for this PR:

• master
  • PR Refactor OkHttp interceptors and turn them into Kotlin #32
    • PR Only rebuild response in OkHttp interceptor if we modify the body #33
      • PR Improve offset calcuation and application when normalizing to SDK clock #34 👈

This stack of pull requests is managed by Graphite.

[bidetofevil]

I improved the tests to tighten up the evaluation criteria, consolidate logic, and test more cases.

This was prompted by an intermittent failure, which revealed some gaps.