Expose RecvStream::poll_read & poll_read_chunk

[jean-airoldie]

Closes #1782

[jean-airoldie]

Now for this one, the poll_read_chunk is not part of AsyncRead, so technically this would force you to support that new method, but I figured that if it might result in improved read performance, that might be desirable to expose too.

[jean-airoldie]

In my use case, I'm thinking of using poll_read to read the size prefix, followed by poll_read_chunk to read the actual message, for instance.

[Ralith]

I figured that if it might result in improved read performance, that might be desirable to expose too.

This is speculative. I'd prefer to avoid further complicating our API without a concrete use case that benefits, particularly as using poll_read_buf correctly is itself complex. For example, your use case would need to handle consuming any number of chunks before reaching the desired total length, and you'd then have to either deal with having non-contiguous data in whatever downstream processing you do, or copy everything into a single buffer, at best duplicating the logic already provided by poll_read.

[jean-airoldie]

This is speculative. I'd prefer to avoid further complicating our API without a concrete use case that benefits, particularly as using poll_read_buf correctly is itself complex.

Fair enough. In my understanding, the potential benefit was from the unordered read, even if you have to copy the chunks into a separate buffer, in the same way the read_to_end method is implemented.

[djc]

(Needs a rebase. Would be nice if you can squash the commits here.)