Specify framing mode

[bemasc]

Fixes #41, #42

[ekr]

Do we need to say how you also need an in-order transport?

[bemasc]

I had intended this to be usable even on out-of-order transports. It appears to be safe for DTLS 1.3, because the only messages sent in plaintext are ClientHello, ServerHello, HelloRetryRequest, and Alert, each of which constitutes an entire "flight" and so is at no risk of reordering. All multi-message flights are in ciphertext, and can rely on the unified header's sequence number for ordering.

This would not have worked in DTLS 1.2, and I suppose it is not guaranteed for future versions. Perhaps we can nonetheless rely on this property for now, and address the problem if it arises in the future.

I'm not 100% sure how this interacts with the DTLS ACK and retransmission system, but it seems reasonably straightforward to deduplicate identical ServerHellos, to avoid placing a retransmitted ServerHello in the transcript twice.

[ekr]

I don't think you can rely on the sequence number for reordering because retransmits use a new sequence number.

[bemasc]

I had been thinking that we would change that, but never mind.

I've added a CTLSDatagramHandshake type that has a message_seq field for reordering.

[bemasc]

FYI, this PR now moves profile_id out of the ClientHello back into CTLSPlaintext (now called CTLSClientPlaintext). This avoids confusing questions about how to demultiplex profiles that use different handshakeFraming modes.

[ekr]

LGTM.