Migrate from backoff to backon

[nightkr]

Motivation

backoff has been unmaintained for a while now, which is starting to cause rustsec warnings (#1635). backon is a maintained alternative.

Fixes #1635.

Solution

This PR migrates all uses of backoff to backon. This is a pretty breaking change for anyone who interacts with our backoff system beyond letting Controller use its default.

backon::Backoff doesn't have an equivalent to backoff::Backoff::reset, so this PR adds a new ResettableBackoff wrapper system for those use cases.

[nightkr]

Hm, locally all tests pass except for test::pod_can_exec_and_write_to_stdin_from_node_proxy, since that assumes that it is executed from a machine with a running kubelet. nvm it works after I enable port forwarding for it.

[nightkr]

/cc @Xuanwo

[nightkr]

Hm, really not sure about what's still making tarpaulin unhappy.. :/

[clux]

some minor nits and naming questions, but looks sensible.
did not expect to have two backon PRs today 😅

[clux]

has rustdoc gotten smarter lately? this stuff used to give broken links when running just doc

[nightkr]

Ah, damn. You're right.. clippy lead me astray. Will revert.

[nightkr]

Nevermind, this actually seems to have come from the --no-deps flag given by just doc. Removing that generates the links correctly.

[clux]

hopefully this is how docs.rs builds docs. i tried to find some info on this, but not much on their docs. it is possible to inject rustdoc args though, so should probably be fine

[nightkr]

Looks like the code that controls the arguments is https://github.com/rust-lang/docs.rs/blob/5ec4326126b2f244442f55f0183ca7523611f0df/crates/metadata/lib.rs#L253-L300. Building it as RUSTC_BOOTSTRAP=1 cargo rustdoc --lib -Zrustdoc-map --all-features -- --cfg docsrs does seem to work, and links to the corresponding docs.rs entries.

[clux]

I do see the other PR is sidestepping this by adding a trait instead. https://github.com/kube-rs/kube/pull/1653/files#diff-32fcc57da3d0b322998a85b05a1a82dae3f76df733b8a878efa1c97695af386eL3-R13

not sure if this is better or not, but it's possibly less abstraction overhead?

[nightkr]

That PR requires you to implement its Backoff trait manually for each use case, which adds a lot of (code) overhead, especially for downstream users that would be subject to the orphaning rules.

[clux]

True, but are there realistically that many people that would need to tweak backoff behavior? Do we need to optimise for those people? We don't have examples/ to show people how to do it (which to me is indicative that this is not super high value). I can only think of people trying to use it as a half-baked solution to extremely tight consistency guarantees (by hammering the api-server more during network stress) - and that feels not like something we want to encourage. Maybe I am missing something?

The downside to this is complexity of our side; 4 types that we expose from utils/mod (with relations that are hard to decipher), a generic type that sneaks its way into type signatures (in an already complicated controller/mod).

[nightkr]

True, but are there realistically that many people that would need to tweak backoff behavior?

It just feels weird that it becomes.. almost composable, but not quite. Especially since there ends up being a lot of stutter in the implementation (looking at their PR, they have to hard-code the same constants in both ::new() and ::reset()).

a generic type that sneaks its way into type signatures (in an already complicated controller/mod).

We should be able to hide that by integrating it into the implementation of StreamBackoff.

[nightkr]

We should be able to hide that by integrating it into the implementation of StreamBackoff.

Ah right no, since BackoffBuilder doesn't make sense as a trait object, so that complicates the type of Controller.

[clux]

not sure about tarpaulin either. ci is has tarpaulin pinned to 0.28.0 (so should not be a new version thing), and it should otherwise run equivalently locally with just tarpaulin. last stuff was a test failure in crd_derive_schema so maybe that had a stray failure? re-running.

[nightkr]

Might be related to this error in the middle of the compile log..

/home/n/Documents/kube-rs/target/debug/deps/kube_derive-81b5765bf8276125: error while loading shared libraries: libstd-ca74a2d9c5166d9f.so: cannot open shared object file: No such file or directory

That doesn't happen if I use the Rust 1.82.0 toolchain instead (and tarpaulin completes successfully).

[nightkr]

#1658 seems to have sorted out the CI issues at least.