Back off from a short first wait instead of a flat 200 ms

[otsobide]

Fixes #48.

wait_for_completion slept a fixed 200 ms before asking a second time, so a job the server had already finished still cost the caller that much of the client sleeping. The wait now starts at 10 ms and doubles to the old 200 ms ceiling: 10, 20, 40, 80, 160, 200, 200, ...

Measured

Real CLI against a real collapse-server-backend, four runs each, first discarded as warm-up.

input	before	after
5 bytes	236, 233, 237 ms	44, 44, 42 ms
60 MB incompressible (~8.3 s job)	8347, 8550, 8562 ms	8271, 8479, 8297 ms

The small file reproduces the ~235 ms the issue reported. The long job is unchanged: it reaches the ceiling after 310 ms and stays there.

It is not uniformly faster, and that is pinned

A job that finishes just after the ramp is asked again a whole ceiling later, where the flat schedule might have caught it sooner. At 199 ms the old schedule finished at 200 and this one finishes at 310.

The bands are narrow, the worst case across 0 to 2000 ms is 110 ms, and it is bounded by one MAX_POLL_DELAY. the_backoff_is_never_worse_by_more_than_one_ceiling asserts the bound, and it also asserts the worst case is not zero, so it fails if it ever stops measuring anything. everything_that_finishes_inside_the_ramp_is_faster_than_before holds the other side for every job under 150 ms.

Worth stating plainly since the issue only asked about the fast case.

The seam

The first version of this was only reachable through a socket and a real thread::sleep, so the single test drove a stub server and asserted on a wall clock with a 400 ms margin. That proves the fixed interval has not come back and little else.

waiting now holds the loop behind two one-method traits:

pub trait Sleeper { fn sleep(&self, delay: Duration); }
pub trait Poller  { fn poll(&self) -> Result<Progress, RemoteError>; }

RealSleeper and a private HttpPoller are the production pair. Between them a test states the thing no stub server can state deterministically: a job that takes exactly N milliseconds. The fake sleeper accumulates virtual time instead of spending it; the fake job reads that accumulation to decide whether it is done.

wait_for returns Waited { polls, slept }, its own account of what it did. That is what keeps the tests honest: asserting on the return value is asserting on the subject, while reaching into a fake to count calls is asserting on the fake and passes when the fake is wrong.

The schedule moved out of protocol with it. That module answers "what does this JSON mean"; how often to ask is a different question.

Tests

Ten in tests/waiting.rs, running in microseconds because none of them sleeps. Each of these mutations was applied and is caught by several cases:

mutation	tests that fail
start at the ceiling (the old behaviour)	6
never grow the delay	4
sleep before asking	7
do not count the settling poll	3
remove the ceiling	3

The stub-server test in tests/client.rs stays. It is the only thing proving RealSleeper and HttpPoller are actually wired in, rather than the policy being right in isolation.

Not in scope

#71 is still open and lives in the same loop. There is no deadline, no maximum number of polls and no per-request timeout, so a server that answers compressing forever still hangs the caller forever. A backoff changes how often it asks, not whether it stops. The seam added here makes it a few lines, and a Sleeper that reports elapsed virtual time makes it testable the same way.