Function forward_datagrams 

async fn forward_datagrams(
    source: &Transport,
    dest: &Transport,
    side: ProxySide,
    ctx: &ForwardCtx,
) -> Result<(), ProxyError>

Forward datagrams from source to destination.

Datagrams have no queue: they are per-connection and unordered by definition, so a FIFO would impose ordering the protocol does not have. Delay and Hold are refused at this site.

Datagrams are policed, not paced

A datagram is admitted or discarded on arrival, against its class’s bucket, and never queued. That is not a reduced form of what the stream path does — it is the only sound form for this carrier. A queue would impose a delivery order the protocol does not have, and there is nothing a delay could protect: a datagram carries one Object whole, has no successor whose framing is written against it and no stream whose object IDs would need renumbering behind a hole. So the two things that make a stream unit’s discard expensive are both absent, and the arriving unit is the right one to drop.

The decision is taken before the hook, exactly as stream admission is, and for the same reason: showing a hook a unit the engine has already decided to discard would let it return Replace and report an ActionApplied for a wire change that never happened.

Class::Default and Class::Unshapeable name no bucket, so an unclaimed datagram and one whose header did not decode are both admitted unconditionally — which is what makes a configured class’s figures mean something rather than absorbing everything the session sent.

Cost to an unshaped session: one Option::as_ref per datagram, and no header decode it was not already doing — tests/interest_none.rs compares a whole Counters and a byte pump, and this must not move either.