Intentionally disable fragmenting KeyUpdates

[lrstewart]

Resolved issues:

Partially addresses #3432

Description of changes:

While working on a more general solution for fragmenting post-handshake messages, I ran into some issues with KeyUpdates.

Our usual fragmentation story is:

1. Write full handshake message to a stuffer, ie, handshake.io. This is handled by message-type-specific logic.
2. Send a record. This is handled by common message-type-agnostic logic.
   1. Write the record header to conn->out
   2. Copy a fragment of the handshake message to conn->out
   3. Encrypt the record
   4. Send the record (this step can block)
   5. Repeat until full message consumed

With a KeyUpdate, we need to change the encryption key after sending the message. So if the KeyUpdate message is fragmented, then we need to trigger some KeyUpdate-specific logic AFTER moving on to the common fragmentation / record-writing logic.

We could of course do that. I thought of several methods to solve that problem, but all of them-- and I'd argue, any possible solution-- will make KeyUpdates more complex. And we don't gain much from that extra complexity, since the KeyUpdate message is only 5 bytes and the absolute minimum fragment size we support is 2 bytes. We'd be making the code more complex to save 3 bytes, and any solution will cost at least 1 byte of stored state.

So rather than implement fragmentation for KeyUpdate messages, I think it's a cleaner solution to just bump the minimum send buffer size up by 3 bytes so that we always ensure that there's sufficient space for a KeyUpdate message.

The only use case I can think of for setting your send buffer that low is that you know that you'll always only be sending a few bytes of application data. This seems unlikely to break anyone. There's also precedent, since we already bumped the minimum up by 1 byte in 4f3c16d to properly handle alerts.

An alternative that wouldn't change any behavior is to keep the current minimum, but error when sending a KeyUpdate message if the send buffer is too small. Since we currently only send a partial KeyUpdate if the send buffer is too small, the connection already fails if it requires a KeyUpdate and the send buffer is too small. We could note this behavior in the method documentation, but it seems like an unnecessary sharp edge and I'd rather prevent it.

Callouts

• The include changes to seemingly random files are side effects of resolving problems caused by adding the new includes to s2n_config.h for the constants the new macro uses.
• Watch out for me mixing up fragment size and record size / send buffer size in my documentation. I kept doing it -_- I think I fixed it everywhere, but keep an eye out.

Testing:

New unit tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.