SocketsHttpHandler: Support zero-byte read on response streams

[geoffkizer]

Supporting zero-byte read helps users of these APIs reduce memory usage. It allows them to release their read buffers when no data is currently available.

We should support this in our HTTP response streams in SocketsHttpHandler, including RawConnectionStream since this is used for WebSockets and tunneling scenarios.

Ideally we would also release our own read buffer (if any and if possible) and issue a zero-byte read against the underlying connection. This is what SslStream does (as of 6.0). The idea here is that the user has indicated their interest in minimizing buffer memory usage, and so we should do the same for our own internal buffers.

I split this issue off from #61223.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Supporting zero-byte read helps users of these APIs reduce memory usage. It allows them to release their read buffers when no data is currently available.

We should support this in our HTTP response streams in SocketsHttpHandler, including RawConnectionStream since this is used for WebSockets and tunneling scenarios.

Ideally we would also release our own read buffer (if any and if possible) and issue a zero-byte read against the underlying connection. This is what SslStream does (as of 6.0). The idea here is that the user has indicated their interest in minimizing buffer memory usage, and so we should do the same for our own internal buffers.

I split this issue off from #61223.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[karelz]

Triage: We have multiple customers who might benefit from this (savings in COGS) -- gRPC and 2 partner teams.

We might want to double check if SslStream 0-byte reads do not allocate. It might not be 100% working there. We do not have perf coverage here.

[karelz]

Partial fix is also in 6.0.9 (see PR #72804)