Function forward_control_stream 

async fn forward_control_stream(
    client: &Transport,
    relay: &Transport,
    ctx: &ForwardCtx,
    client_leg: ControlLeg,
    upstream_leg: ControlLeg,
) -> Result<(), ProxyError>

Forward the control stream on the drafts whose control stream is the first client-initiated bidirectional stream — drafts 07 through 16.

Drafts 17 and later do not reach this function at all: they put the control plane on a pair of unidirectional streams and use bidirectional streams for requests, so their two control directions are picked out of the unidirectional accept loop by classify_uni_stream and their bidirectional streams are forwarded by forward_request_streams. See control_plane_is_unidirectional for which drafts those are and what the drafts say.

Draft-16 reaches it and has request streams. The first bidirectional stream this function accepts is its control stream, and every one after it is a request stream taken by request_streams_beside_the_control_stream, which runs as a branch of the select! at the end rather than as a task of its own — see there for why the ordering has to be settled by the code.

client_leg and upstream_leg are the two request channels the control plane reaches this session’s control stream through, and the mapping between them and the two pipes is a half-turn worth stating: a message the client is meant to decode is written by the pipe that forwards from the relay, because that is the pipe holding the client-facing write half. The registry gets the same senders under the two direction keys, so a reset_stream naming either control direction reaches the same task an injection would.