Make duration calculation robust against clock drift

[bkchr]

It is possible that Instant::now() is returning an earlier clock time when being called a second
time. To guard against this, we should use saturating_duration_since.

Fixes: paritytech/polkadot#4096

[arkpar]

Documentation clearly states that Instant is monotonic and is not affected by the system clock drift. We rely on that all over the code.

Instants are always guaranteed to be no less than any previously measured instant when created

I think the issue here is that Instant::now is called on two different threads, leading to a race condition. Apparently it is not guaranteed to be monotonic across CPU cores. Here's a relevant stackoverflow discussion: https://stackoverflow.com/questions/46893072/clock-gettimeclock-monotonic-monotonicity-across-cores-threads

[bkchr]

Documentation clearly states that Instant is monotonic and is not affected by the system clock drift.

Yeah I know. However, afair, we already have seen this in virtual machines as well. That it returned different values per call.

[bkchr]

bot merge

[paritytech-processbot]

Bot will approve on the behalf of @bkchr, since they are a team lead, in an attempt to reach the minimum approval count