fix(http1): withdraw a stale want when the client dispatcher takes a request

[shodoco]

Closes #4207.

Draft: blocked on seanmonstar/want#6. The fix calls want::Taker::unwant(), which no want release has yet. The second commit patches want to that PR's branch so this builds and CI can run. Once want is released, I'll replace that commit with a want version bump and mark this ready for review.

The problem

An HTTP/1 SendRequest reports ready through a shared want flag. The connection task sets it when it finds its request queue empty, and send_request clears it with give() before queuing a request. The task's want() can land after that give(), so the request is taken with the flag still set. There are two ways, both described in #4207:

• The task finds the queue empty, then send_request runs on another thread before the task calls want().
• tokio's coop budget makes the queue return Pending with the request already in it.

While a request is in flight, the dispatcher doesn't poll the queue, so nothing clears the flag until the response is complete:

sequenceDiagram
    participant S as SendRequest
    participant F as want flag
    participant T as connection task
    Note over F: Want (connection idle)
    S->>F: give(): Want → Idle
    S->>T: request queued
    rect rgb(255, 228, 228)
    T->>F: want(): Idle → Want (stale)
    end
    T->>T: poll_recv: Ready(request)
    Note over T: writes the request and reads the response
    S->>F: is_ready()? true, with the request in flight

Loading

hyper-util's legacy pool checks is_ready() when a response head arrives. So it pools the busy connection, and the next request is written only after the whole previous response has been read.

The fix

When Receiver::poll_recv takes a request, it withdraws any outstanding want with taker.unwant(), a compare-exchange from Want to Idle. The task signals want again only when it is idle and polls an empty queue.

sequenceDiagram
    participant S as SendRequest
    participant F as want flag
    participant T as connection task
    Note over F: Want (connection idle)
    S->>F: give(): Want → Idle
    S->>T: request queued
    T->>F: want(): Idle → Want (stale)
    T->>T: poll_recv: Ready(request)
    rect rgb(222, 245, 222)
    T->>F: unwant(): Want → Idle (new)
    end
    Note over T: writes the request and reads the response
    S->>F: is_ready()? false until the connection is idle

Loading

When no stale want is set, unwant() finds the flag Idle and does nothing. HTTP/2 is unaffected: its is_ready() only checks whether the connection is closed.

A sender-side reorder (queue the request, then give()) isn't enough. The task's late want() can still land after the give(), and the coop path doesn't depend on the order at all.

Tests

tests/h1_ready_in_flight.rs drives the coop path deterministically, using only the public API. It drains the task's coop budget before polling the connection, so the queue returns Pending with a request in it. Then it checks that is_ready() is false once the request is taken.

• cargo test --features full --test h1_ready_in_flight: passes. With the unwant() line removed, it fails at the final assert!(!sender.is_ready()), as it does on master.
• cargo test --features full: 313 passed, 0 failed, 10 ignored.
• rustfmt --check is clean on the changed files.

The test uses tokio::task::coop::poll_proceed, which is public since tokio 1.47. The tokio dev-dependency is "1", and CI resolves the latest version. I can raise it to "1.47" if you'd prefer.