Mitigate panics due to falsely monotonic clocks

Example backtrace on arm64:

/lib/arm64/libnativetunnel.so (core::option::expect_failed::h4b77ebe6e62ec3a1+64)
/lib/arm64/libnativetunnel.so (std::time::Instant::duration_since::h632e3fc95ad5458d+68)
/lib/arm64/libnativetunnel.so (boringtun::noise::timers::_$LT$impl$u20$boringtun..noise..Tunn$GT$::update_timers::hc9bb6fc49d2aed16+2688)

This should never happen, but yet it does - so apply some defensive
programming.

Author: cbranch

src/noise/timers.rs

@@ -78,7 +78,7 @@ impl Timers {
     // We don't really clear the timers, but we set them to the current time to
     // so the reference time frame is the same
     pub(super) fn clear(&self) {
-        let now = Instant::now().duration_since(self.time_started);
+        let now = self.time_started.elapsed();
         for t in &self.timers[..] {
             t.set(now);
         }
@@ -164,6 +164,10 @@ impl Tunn {
 
         let time = Instant::now();
         let timers = &self.timers;
+        // This should be unnecessary, but we observe actual panics in the wild
+        // where both clock monotonicity *and* the Rust stdlib protections
+        // against nonmonotonic clocks violate their contracts.
+        let time = if time > timers.time_started { time } else { timers.time_started };
 
         if timers.should_reset_rr {
             self.rate_limiter.reset_count();