Support for automatic rekeying

[norrisjeremy]

Add support for automatic rekeying as recommend by RFC 4253 & RFC 4344.

• RFC 4253 section 9 states the following:

  It is RECOMMENDED that the keys be changed after each gigabyte of
  transmitted data or after each hour of connection time, whichever
  comes sooner.  However, since the re-exchange is a public key
  operation, it requires a fair amount of processing power and should
  not be performed too often.

• RFC 4344 section 3 states the following:

  
  Section 9 of [RFC4253] suggests that SSH implementations rekey after
  every gigabyte of transmitted data.  [RFC4253] does not, however,
  discuss all the problems that could arise if an SSH implementation
  does not rekey frequently enough.  This section serves to strengthen
  the suggestion in [RFC4253] by giving firm upper bounds on the
  tolerable number of encryptions between rekeying operations.  In
  Section 6, we discuss the motivation for these rekeying
  recommendations in more detail.

This section makes two recommendations. Informally, the first recommendation is intended to protect against possible information leakage through the MAC tag, and the second recommendation is intended to protect against possible information leakage through the block cipher. Note that, depending on the block length of the underlying block cipher and the length of the encrypted packets, the first recommendation may supersede the second recommendation, or vice versa.

* [RFC 4344 section 3.1](https://datatracker.ietf.org/doc/html/rfc4344#section-3.1) states the following:

Because of possible information leakage through the MAC tag, SSH implementations SHOULD rekey at least once every 232 outgoing packets. More explicitly, after a key exchange, an SSH implementation SHOULD NOT send more than 232 packets before rekeying again.

SSH implementations SHOULD also attempt to rekey before receiving more than 232 packets since the last rekey operation. The preferred way to do this is to rekey after receiving more than 231 packets since the last rekey operation.

* [RFC 4344 section 3.2](https://datatracker.ietf.org/doc/html/rfc4344#section-3.2) states the following:

Because of a birthday property of block ciphers and some modes of operation, implementations must be careful not to encrypt too many blocks with the same encryption key.

Let L be the block length (in bits) of an SSH encryption method's block cipher (e.g., 128 for AES). If L is at least 128, then, after rekeying, an SSH implementation SHOULD NOT encrypt more than 2(L/4) blocks before rekeying again. If L is at least 128, then SSH implementations should also attempt to force a rekey before receiving more than 2(L/4) blocks. If L is less than 128 (which is the case for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then, although it may be too expensive to rekey every 2**(L/4) blocks, it is still advisable for SSH implementations to follow the original recommendation in [RFC4253]: rekey at least once for every gigabyte of transmitted data.

Note that if L is less than or equal to 128, then the recommendation in this subsection supersedes the recommendation in Section 3.1. If an SSH implementation uses a block cipher with a larger block size (e.g., Rijndael with 256-bit blocks), then the recommendations in Section 3.1 may supersede the recommendations in this subsection (depending on the lengths of the packets).

[norrisjeremy]

@mwiede FYI, I'm slowly working on implementing this. My in-progress work encompasses some significant cleanups and thread-safety fixes for Session.java, so the resulting changeset will be rather large.