Remove Kestrel Pipe pause and resume thresholds and be more preemptive about sending large available frame sizes.

[jkotalik]

We hit this issue with #7964. The fundamental issue is that if we are calling context.Request.BodyPipe.ReadAsync() and then call AdvanceTo(buffer.Start, buffer,End) (examine without consuming), we will eventually get to a point where we buffer PipeReader too far and it would cause backpressure OR in the case of HTTP2 send a frame update saying that the client shouldn't send more data. We decided that this shouldn't be fixed by the parsers and instead should be fixed in Kestrel.

A few things will happen between Kestrel and Pipelines

• The pause and resume thresholds should be removed and limits should be enforced in parsers.
• When calling PipeWriter.AdvanceTo, it should never throw where there is backpressure and the thresholds should be a soft limit. In this case, we can keep the limits in Kestrel.

[jkotalik]

cc @davidfowl @Tratcher

[jkotalik]

We probably want this in preview4, correct?

[Tratcher]

Yes, the form reader needs this.

HTTP/2 clarification: When there's backpressure it's signaled via the absence of window update frames, not by a special frame asking the client to stop.

• Change: Send window updates based on Examined rather than Consumed (and remove the buffer limits).

[jkotalik]

Ah didn't realize that the lack of window updates is what causes the client to stop.