Function request_streams_beside_the_control_stream 

async fn request_streams_beside_the_control_stream(
    client: &Transport,
    relay: &Transport,
    ctx: &ForwardCtx,
) -> Result<(), ProxyError>

The client-to-relay loop for bidirectional streams beside a bidirectional control stream: draft-16’s request streams (see bidi_streams_carry_requests), or on 07-15 streams the draft does not define.

Why it is a branch of the control stream’s select! and not a task

Because both take bidirectional streams off the same transport, and only one accept may be outstanding if the first one is the control stream is to mean anything. Running here, the loop starts after forward_control_stream has already taken the control stream, so the order is fixed by the code rather than by which task the runtime polled first. A separate task racing the same accept_bi would forward the control stream as a request stream on whichever runs of whichever build happened to lose.

The relay-to-client direction has no such constraint — nothing else accepts a relay-initiated bidirectional stream — so it is spawned as an ordinary loop beside this function’s caller.

On drafts 07-15 the streams it takes are forwarded unread by forward_undefined_bidi_streams.