A burst of concurrent requests during half-open all get admitted at once

Half-open exists specifically to send a trickle of probe traffic (by default, one request) at a just-recovered upstream, instead of slamming it with the full concurrent load the gateway was holding back -- an upstream that is recovering from an outage is often still fragile, and a sudden thundering herd of every previously-blocked request landing on it at once can knock it right back down, defeating the entire purpose of having a gradual recovery probe. Under concurrent traffic, that is exactly what happens today: as soon as the recovery window elapses, a burst of concurrent requests all get admitted as "probes" at once, regardless of half_open_max_probes.

Breaker.acquire()'s half-open branch checks self._half_open_probes_in_flight >= self._half_open_max_probes and, if there is room, does await asyncio.sleep(0) (yielding to the event loop) before incrementing the counter.

1. Build a Breaker with failure_threshold=1, recovery_timeout_seconds=10, half_open_max_probes=1, trip it, and advance its clock past the recovery window.
2. Fire 20 concurrent acquire() calls via asyncio.gather.
3. Observe: all 20 are admitted (the printed "admitted" count is 20), instead of exactly 1.

This is a genuine, reproducible race, not a theoretical one: the await asyncio.sleep(0) between the read of _half_open_probes_in_flight and the write to it is a real suspension point, so many concurrently scheduled tasks interleave their reads before any of them commits its write -- classic check-then-act-without-a-lock-around-both-steps. Removing the await would not be a fix on its own if the check is still outside the lock scope that covers it; the check-and-increment need to happen as one atomic unit with respect to every other concurrent caller.

Compare this method to on_success()/on_failure(), which both do their entire read-check-write under a single with no in between the read and the write. 's half-open branch does not have that shape. Whatever fix you land on, the check-and-increment together need to be atomic with respect to every other concurrent call to -- and it should still be possible for a real request's call to happen without holding a lock across the actual network call that follows it (that part of the pipeline is in , not in at all, and is correctly unaffected by this bug).