Function pump_control_leg 

fn pump_control_leg(
    leg: ControlLeg,
    inbox: Sender<StreamCommand>,
) -> AbortOnDrop

Hand one control leg’s requests to the stream that turned out to be that direction’s control stream.

The leg’s channel exists from the moment the session registers, which is before any stream has arrived, so an injection can be accepted for a session whose control stream has not been established yet — that is the promise crate::control::ProxyControl::inject_control makes. On the drafts where the control stream is picked out of the unidirectional accept loop, the task that will serve it is not known until its first varint has been read, so the leg is pumped into that stream’s own inbox once it is: the same inbox the registry hands a reset_stream to, so one task serves both verbs and they stay in the order they were asked for.

The returned guard ends the pump when the stream’s task ends. A request still in the leg’s channel at that point stays there and is discarded with the session, which is the outcome inject_control documents for every message it accepts and cannot place.