Should the worker thread receive a Stream of Operations, and output a Stream of completed operations?

[JackKelly]

Pros

• Makes it easy to enable a pipeline of concurrent steps. (See issue Multiple threads (each with a uring) & crossbeam::deque & a pipeline of I/O steps #61).
• This should make it even easier to implement BatchObjectStore (Define a new BatchObjectStore trait. Start with just a single method: get_batch(Vec<operations>) -> Stream. #32 & impl BatchObjectStore for IoUringLocal. Implement just get_batch. #33)
• It should still be easy to implement ObjectStore. The io_uring thread would just check if the Operation's send_output_to is Some and, if it is, send the finished Operation to that Sender instead of yielding an output Stream?
• This would fit nicely with also having a Stream (or crossbeam::channel) for the user to indicate which buffers can be re-used (Re-use buffers #38).

Blocked by

• Replace OperationFuture with tokio::sync::oneshot? #43

Questions / further research required

• Should we use Streams or crossbeam::channel? The advantage of crossbeam::channel is that it can use multiple Sender threads and multiple Receiver threads.

[JackKelly]

This is basically a duplicate of #61