Refactor/optimise code sending TLS control channel messages

Refactor/optimise code sending TLS control channel messages

This commit originally tried to solve a problem that the SSL library
might split up a control frame into multiple TLS records when doing
multiple reads. However, this does not seem to be actually the case.

OpenVPN will consider a control message packet complete
when the TLS record is complete, we have to ensure that the SSL library
will still write one record, so the receiving side will only be able
to get/read the control message content when a TLS record is
complete.

To improve handling of large control channel messages, this
commit does:

- Split one read from TLS library into multiple control
  channel packets, splitting one TLS record into multiple
  control packets.
- increase allowed number of outstanding packets to 6 from 4 on the
  sender side. This is still okay with older implementations as
  receivers will have room for 8. This allows transmitting larger
  control message more quickly.
- take the wrapped key length into account when sending packets
  This is especially important for the tls-crypt-v2 P_CONTROL_WKC_V1
  message
- calculate the overhead for control channel message to allow
  staying below that threshold.
- remove maxlen from key_state_read_ciphertext and related functions.
  We now always give the function a correctly sized buffer.

If we end up needing to send a packet larger than max-packet-size, we
warn about it but still do it as it might still work, while refusing to
send will never work.

Patch v2: avoid assertion about to large buffer by sticking to 1250 max
          control size in this commit and leaving larger sizes for the
          --max-packet-size commit. Also fix
          various other small problems and grammar fixes.
Patch v3: grammar fixes
Patch v4: adjust tls-mtu to max-packet-size in message.
Patch v6: no longer make the assumption that multiple reads from the SSL
          library split a control frame into multiple TLS records.

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20221104125655.656150-1-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25478.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>