Improve boundary between connection and protocol

[DanielSank]

From Matthew's email

I might also suggest changing the boundary between what you've called "Protocol" and "Connection". Right now, the Protocol class deals with reconstructing bytes from the stream and also writes raw bytes to the transport. It seems like it would be better to have the framing and encoding/decoding handled by the "network" layer, then you can layer the RPC protocol on top of that, namely the contents of the messages, matching requests and responses, etc.

[DanielSank]

I am a bit puzzled by what to do here. I think there are three stages involved in any for of RPC code:

1. Asynchronous task creation, suspension, and resurrection. When a request comes in, we must create some kind of worker (e.g. a thread, or in the case of python asyncio a Task) to handle it. If that task suspends, likely to make its own outgoing request, we must later wake that task up when the result of the outgoing request has been received.
2. Parsing the wire data. Data comes in as a stream of bytes. Those bytes need to be framed into individual messages and unflattened into some form of in-memory data structure.
3. Interpreting the unflattened data according to some communication protocol.

I'm trying to understand the separation between unflattening binary data and interpreting the unflattened data in a particular protocol. I'm also not exactly sure how the asynchronous task delegation separates from unflattening.