drpcstream: per-stream receive window and read-path grant wiring

[suj-krishnan]

1. Per-stream receive-window grant policy (recvWindow).
Tracks buffered bytes (in-progress reassembly + completed, not-yet-consumed) and decides when to return credit: withholds grants while buffered is at/above the high-water mark, otherwise releases accrued returnable credit once it reaches the threshold. dispatched/consumed return the credit delta to emit; consuming reopens a gate the high-water mark had closed.

2. Read-path wiring.

• HandleFrame intercepts an incoming KindWindowUpdate before the assembler and applies it to the send window. Intercepting early keeps a grant that interleaves with an in-progress message (grants are emitted off the write lock) from disturbing reassembly.
• Discarded partials release their bytes: the assembler silently can drop an unfinished message when a higher message id supersedes it. Those bytes were dispatch-counted and would inflate buffered forever, causing the high-water gate to shut. So, the assembler now reports the drop (TakeDiscarded) and HandleFrame releases the bytes as consumed, so their accrued credit flows back.

[shubhamdhama]

Quick comment: the three commits in this PR aren't independent. The last two commits should definitely be squashed and to make sense of how receive_window is going to be used that commits needs to be with the above squashed commits. I would suggest squash all three commits.

[shubhamdhama]

I think this much of the comment would be enough.

// Intercept before the assembler so one
// arriving mid-message cannot disturb reassembly.

[shubhamdhama]

My current understanding of this design is that pending tracks credit that has not yet been returned, while buffered tracks bytes held in partial reassembly or completed messages. HandleFrame adds to both and may emit a grant immediately while buffered is below highWater. MsgRecv and RawRecv reduce buffered and may flush grants that were withheld after reaching highWater.

Is that understanding correct? If so, why do we need to emit grants from HandleFrame? Why not emit them only when a message leaves receiver-owned storage in MsgRecv or RawRecv, along with the error and discard paths that release storage?

I can see that the current approach returns credit earlier instead of waiting for the application to consume the message. That may improve throughput by keeping the sender moving, but it also makes the model harder to reason about. Unless we have benchmarks showing that application-level grants are too slow, this feels like a premature optimization. We can add a frame-level fast path later if we find that we need it.

Another possible reason for the fast path is a message larger than the sender's available window. The sender could exhaust its credit halfway through the message, while the receiver cannot return credit through MsgRecv because the message is incomplete. However, the current policy only helps up to highWater. For example:

initial window: 1 KiB
highWater:      8 KiB
message size:  16 KiB

The receiver can return credit as frames arrive until approximately 8 KiB is buffered. It then stops granting credit to apply backpressure. The sender eventually exhausts its remaining credit, the message remains incomplete, and MsgRecv still cannot consume it. The policy moves the stall point from the initial window to roughly highWater plus any remaining credit, but it does not solve the general problem.

I think flow control should operate at packet boundaries instead. Once a packet is admitted, let the sender finish it even if its credit becomes negative. Then block the sender from starting another packet until the receiver consumes the first one and returns its credit. This keeps the receive-side model simple and avoids stopping in the middle of something that DRPC can only consume as a complete packet.

This allows one packet to exceed the window, so we would still need a maximum packet size to bound memory usage. Even with that trade-off, I think we should start with the simpler model and add frame-level grant behavior only if we can show that it is needed.