[rksm]

MaybeBackoff::arm() now builds its ExponentialBackoff with no elapsed-time limit. An armed MaybeBackoff keeps waiting between attempts for as long as the caller retries.

Problem

arm() set the initial delay, the maximum delay, the multiplier, and the randomization factor. It did not set max_elapsed_time, so the backoff kept the ExponentialBackoff default of 15 minutes. After 15 minutes, next_backoff() returned None, and sleep() returned at once. A loop that retries forever then retried with no delay at all.

Changes

• arm() calls .with_max_elapsed_time(None). Its doc comment now says that an armed MaybeBackoff always waits and never runs out.
• A unit test moves start_time back by 16 minutes and checks that next_backoff() still returns a delay. The test fails without the fix.
• The version goes up to 0.5.1. We do not publish this version to crates.io. hyper.video pulls it from this repository by commit, and the version bump shows the change in its lockfiles.

Checks

• cargo test --features tokio
• cargo test --doc
• cargo fmt -- --check
• cargo clippy --all-targets --features tokio -- -D warnings
• cargo clippy --all-targets --target wasm32-unknown-unknown -- -D warnings