Implement BufQueue type

[stepancheg]

BufQueue<B: Buf> is a VecDeque<B> which implements Buf and caches the remaining size.

This utility can be used to implement outgoing network buffer. Imagine this use case:

type Header = Cursor<[u8; 5]>;
type Payload = Bytes;
type MyMessage = Chain<Header, Payload>;

outgoing_queue: BufDeque<MyMessage>;

New messages can be queues by simply appending to this BufQueue, and the queue can be flushed by invoking bytes_vectored on the queue object.

And both enqueue and flush operations are zero-copy.

remaining cache is needed to optimize bytes operation, which might be expensive if the queue is long.

I'm not 100% sure this is how Bytes is meant to be used, but this BufQueue type seems to be the most natural way.

[Ralith]

This seems handy, but so long as bytes is an extremely stability-sensitive interface crate I don't know if it should be accepting new self-contained interfaces. Perhaps this could be a separate crate?

[stepancheg]

Perhaps this could be a separate crate?

Or users can simply implement this themselves, BufQueue is not rocket science.

It took me a very long time to figure out how to connect Bytes, Buf and tokio IO interfaces for the described use case. I guess it might be the case for other people too, and some default implementation might be useful for that, at least for illustration.

[seanmonstar]

This seems handy, but so long as bytes is an extremely stability-sensitive interface crate I don't know if it should be accepting new self-contained interfaces.

This has been the stance so far, and is why hyper has the type inlined (and not exposed directly). We've discussed that something similar might make sense like in tokio-codec or tokio-utils or something. But as you've also mentioned, it's not difficult for someone to just have in their own project, it's incredibly small.

[Duckilicious]

I stumbled across this while looking for the standard solution tokio provides for cases where you want to look at a few payloads as one continuous payload and I am bit surprised you don't think this deserves a place in the provided interfaces but something like pub struct Chain<T, U> does. Even if there is somehow a way to use Chain primitive in the same way you use this the remaining() op is still too costly. I think merging this PR would be beneficial.

I feel like the provided API isn't complete without the suggested primitive and I'd like you to reconsider your stance regarding your decision to drop it. Moving the burden for every project that requires something like this and uses tokio to maintain it's own version doesn't seem like a very user friendly approach.