Use tokio::time::Instant as a time source

[olix0r]

Would you like to work on this feature?

maybe

What problem are you trying to solve?

tokio::time::Instant has two important benefits over std::time::Instant (as well as the instant crate):

1. It supports mocking for tests via tokio::time::pause, etc. This allows a test to control how time advances, interacting well with the tokio timers.
2. It avoids panics. Especially on Amazon Linux/EKS, we have reports of time arithmetic causing runtime panics due to bugginess in the OS's time source and Rust's standard library.

Describe the solution you'd like

We should replace uses of std::time::Instant with tokio::time::Instant. We may also want to add a clippy configuration including:

disallowed-types = [
    # Use parking_lot instead.
    "std::sync::Mutex",
    "std::sync::RwLock",

    # Use tokio::time::Instant instead.
    "std::time::Instant",
]

See also:

• Support tokio::time::Instant in SystemClock ihrwein/backoff#53

Describe alternatives you've considered

Don't allow time mocking, wait for Rust std lib to solve panics in Instant.

Documentation, Adoption, Migration Strategy

No response

Target crate for feature

kube-runtime

[clux]

that sounds great to me! if you have time, then happy to take a pr on this.

[nightkr]

We already use tokio::time::Instant in most places because of the mocking, and the case of backoff_reset_timer looks like an oversight. 👍 from me.

[olix0r]

@clux I think it's a pretty trivial PR but, practically, it's probably blocked on ihrwein/backoff#53 -- while we can change the backoff clock, we can't really avoid panics due backoff's calls to duration_since, etc. I'll follow-up here when that PR shakes out a bit.