Problem Statement

The issue is described in #2502: it is possible to get a corrupted packet on the receiving side when encryption is enabled.
The reason is that a data packet may be encrypted with a key different from the one indicated in the KK flied of the data packet header.

The active key (odd/even) switch happens in the RcvQ thread:

CUDT::processCtrlAck(..)
⋅ ⋅ CUDT::checkSndTimers(..)
⋅ ⋅ ⋅ ⋅ CCryptoControl::sendKeysToPeer(..) // Key refresh

The SndQ Thread first sets the KK frags of a data packet, then encrypts the packet, potentially with a different key if KM refresh has happened.

CUDT::packUniqueData(..)
⋅ ⋅ CCryptoControl::encrypt(..)

Steps to Reporoduce

#2502 (comment)

Proposed Solution

Statement 1. KM refresh is performed by the payload sender for the TX context. Thus it should be done in the sending queue, in particular, right after (or just before) encoding the next unique data packet.

Statement 2. KM_REQ retransmission has to be performed from the RcvQ thread, when checking retransmission timers. The same for HS_REQ retransmission. There is no need to do this operation in the processing of an incoming ACK packet.

Proposed Solution. Perform key refresh in the same thread where encryption happens, in particular, right after the encryption of a unique data packet.

Fixes #2502.