Use CLOCK_MONOTONIC_RAW for Instant when available

[sfackler]

Closes #37902

r? @alexcrichton

[nagisa]

I find it dubious to work around a bug in an ancient version of the kernel by using MONOTONIC_RAW.

[sfackler]

CLOCK_MONOTONIC_RAW is a more appropriate clock for Instant regardless since it isn't affected by NTP adjustments.

[Amanieu]

@sfackler See my comment in #37902. We actually do want to take NTP adjustments into account since we want our clock to stay in sync with real time (1 second on clock = 1 real second).

[alexcrichton]

Some thoughts of mine:

• We've seen time.rs should consider using CLOCK_MONOTONIC_RAW instead of CLOCK_MONOTONIC on Linux #37902 at least two times now (Add debug message in time panic #37137 as well). It's unfortunate that these programs panic-by-default.
• To be clear, it seems like this is a kernel bug and not a bug in the standard library. That is, it looks like CLOCK_MONOTONIC is violating what it's documented as doing.

So in light of that I like this approach as it works around buggy kernels in what appear to be somewhat common circumstances. In that sense I think the only question is for systems which have non-buggy versions of both clocks whether we use the raw versions or not (basically @Amanieu's question). I would tend to agree that CLOCK_MONOTONIC seems like the most accurate here in terms of what we'd like to have, although I believe the documentation for Instant would allow both.

Is it possible for us to isolate these buggy kernels? Can they somehow be detected? Do we know for sure that it was a buggy kernel and can track down versions? If we can do that then we could perhaps use the raw clock only on these buggy kernels.

[Amanieu]

We could detect buggy kernels by caching the last value returned by clock_gettime(CLOCK_MONOTONIC) and checking if a newly return value is earlier than the cached value. However this has performance implications since you would need a mutex to serialize calls to clock_gettime, which may not be desirable since this functionality is often used for fine-grained timing (e.g. benchmarking).

[sfackler]

It does depend on your use case - at low durations you'd preseumably prefer the slight inaccuracy of the raw clock over the possibility of measuring inside of an NTP-induced skew.

Seems reasonable that CLOCK_MONOTONIC is a better default choice though.