Fix Deflate/Brotli/CryptoStream handling of partial and zero-byte reads (#53644)

Fix Deflate/Brotli/CryptoStream handling of partial and zero-byte reads (#53644)

Stream.Read{Async} is supposed to return once at least a byte of data is available, and in particular, if there's any data already available, it shouldn't block.  But Read{Async} on DeflateStream (and thus also GZipStream and ZLibStream), BrotliStream, and CryptoStream won't return until either it hits the end of the stream or the caller's buffer is filled.  This makes it behave very unexpectedly when used in a context where the app is using a large read buffer but expects to be able to process data as it's available, e.g. in networked streaming scenarios where messages are being sent as part of bidirectional communication.

This fixes that by stopping looping once any data is consumed.  Just doing that, though, caused problems for zero-byte reads.  Zero-byte reads are typically used by code that's trying to delay-allocate a buffer for the read data until data will be available to read.  At present, however, zero-byte reads return immediately regardless of whether data is available to be consumed.  I've changed the flow to make it so that zero-byte reads don't return until there's at least some data available as input to the inflater/transform (this, though, doesn't 100% guarantee the inflater/transform will be able to produce output data).

Note that both of these changes have the potential to introduce breaks into an app that erroneously depended on these implementation details:
- If an app passing in a buffer of size N to Read{Async} depended on that call always producing the requested number of bytes (rather than what the Stream contract defines), they might experience behavioral changes.
- If an app passing in a zero-byte buffer expected it to return immediately, it might instead end up waiting until data was actually available.