Make communication between Veracruz client and runtime manager simpler and faster.

[egrimley-arm]

The current code seems to be more complex than necessary, for historical reasons, and appears to perform poorly, particularly in terms of latency. Issue #378 has helped a lot, but there is more work to do.

TLS is designed for full-duplex connections, but parts of Veracruz send and receive TLS-encrypted data in a request-response manner, which makes it unclear how to avoid a situation in which both sides are waiting for data from the other side. The Veracruz server should probably operate in a full-duplex way without any such assumptions about the lower-level protocol inside the encrypted packets.

With all of our current platforms, communication with the runtime manager is through something that resembles a socket, so there could be multiple connections to the runtime manager rather than have the Veracruz server multiplex client connections into a single connection into the runtime. (Once an enclave has been established, the Veracruz server would then act rather like multiple instances of socat.)

It may be possible to have a more principled way of detecting when a protocol buffer is complete rather than having our code add length prefixes in an ad hoc way.

[egrimley-arm]

PR #552 is a first step in the work for this issue.

[dreemkiller]

How is this looking now, @egrimley-arm ?

[egrimley-arm]

Kyle is working on something closely related to this: #10