GitLab

It turns out this was a pretty large source of allocations (by number). We might
as well just reuse the same buffer over and over.

The API is significantly cleaner and safer.

1. Respect context. Before, we didn't respect the context when writing/reading
the final nonce.
2. Don't make assumptions about connection buffering. Read/write handshake
messages in parallel.
3. Return messages from ReadMsg to the buffer pool.
4. Close the connection on timeout. We can't reuse it at this point as there may
be an outstanding writer/reader (and we don't allow parallel reads/writes).

Before, we were copying it (dangerously, locks and stuff), into every writer.
Now, we share it (like we should...).

note: I'm not even sure if we should be using buffer pools (the allocator may be
faster in this case) but that's another issue.

License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>

go-msgio implements the message length limit (currently 8MB), so the
secio reader can get away without re-implementing this logic.

Instead, the reader lets go-msgio allocate a buffer when the output
buffer is too small to hold the incoming message. This buffer is kept
and drained into the output buffer(s) of Read() calls and released back
to the msgio instance once it is fully drained.

License: MIT
Signed-off-by: Randall Leeds <randall@bleeds.info>