Today we try to split up large messages in comms.
This is useful in a few situations:

1.  Websockets, which often pass frames through middleware that requires
    small messages
2.  TLS, which fails on some OpenSSL versions with frames above the size
    of an int

We correctly cut up data frames into smaller pieces to address these
issues.  However we don't apply this same logic to the header frame,
which may still contain very large bytestrings.  This commit adds a
workaround in protocol dumps/loads which watches for this event and
splits the header frame up if necessary.

It works, but it's not very smooth.  I would prefer that in the future
we think about what a proper header should look like and ensure that it
contains no user data.  In the meantime this should help.

Currently compression and frame splitting are tightly interwoven with
traversing through messages.  This can be efficient, but results in a
complex system where it's hard to reason about when things get split or
compressed (indeed, this lead to a difficult to track down bug with
frame splitting).

This commit separates these processes into three separate stages:

1.  Serialize all objects into frames
2.  Split large frames
3.  Compress compressible frames

This results in a much more uniform application of splitting and
compressing.  However, this comes with a couple of undesired effects.

1.  We add a new header if either splitting or compressing has occurred
2.  We no longer avoid decompression when we don't want to deserialize

There is probably a clean way to achieve most/all of our goals here.
I wanted to push this up to start this conversation.

…ify-protocol