Move to DER-based socket protocol

[vanrein]

Some pressure is building around the socket protocol:

• Porting it to Windows was difficult; 32-bit clients and 64-bit daemon, that sort of thing
• We now need to use packing pragmas, which are downright ugly
• Sizes may vary in the future, or overly constrain things
• It is weird to pass the entire union; a preceding length would make sense
• The socket is connection-oriented to detect decoupling; it might benefit from preceding length
• Unleashing the socket over a network means we'd need to mind endianness
• Limitations on localid/remoteid sizes may cause problems in the future
• Limitations on flag field sizes may cause problems in the future
• Inability to extend structures may cause problems in the future
• The nested struct/union/struct is far from pleasant to handle all over the place

All this could be remedied with an ASN.1 formulation, and use of DER. Using Quick DER, this should not even be such a stretch. We already use Quick DER in the TLS Pool daemon, and it hardly adds anything to clients. What it would do, is make it possible to use the socket protocol, which became an ill-advised practice on account of the pressure reported above.

[vanrein]

Looks like #42 is (once more) the answer to all our problems :-)

[vanrein]

See #60 for a possible alternative to DER, namely the Diameter EAP-TLS application. This would mean that we can use a standard protocol and not have to invent our own, even if our particular use of it is not what is normally done.

[vanrein]

This (and perhaps alternatives such as XDR or JSON) is the only contender left for remote protocols using the TLS Pool. It is possibly of interest to embedded/small systems.