Reduce frequency of the decryption failure log

[maxsharabayko]

Current Behavior

If SRT fails to decrypt a packet, one error message is printed from CCryptoControl::decrypt(..) :

W:SRT.cn: decrypt ERROR (IPE): HaiCrypt_Rx_Data failure=-1 - returning failed decryption

and one warning is reported from CUDT::handleSocketPacketReception(..):

Decryption failed. Seqno %...

Thus two warnings are printed per single decryption failure. In case of an attack in AES-GCM mode, a lot of data packets may be corrupted, and decryption is expected to fail. That would result in too many warning messages.

The Proposal

This PR introduces a new variable m_tsLogSlowDown to reduce the frequency of some potentially frequent warnings. Currently, only decryption failure warning uses this mechanism.

By default, the following warning will be shown not more often than once per 1 s:

W:SRT.qr: @879501775: Decryption failed (seqno %1229888030), dropped 1. pktRcvUndecryptTotal=5.

The frequency can be set via the SRT_LOG_SLOWDOWN_FREQ_MS definition (available in CMake).

TODO

#ifndef SRT_LOG_SLOWDOWN_FREQ_MS
#define SRT_LOG_SLOWDOWN_FREQ_MS 1000
#endif

[maxsharabayko]

Testing

./srt-xtransmit generate "srt://127.0.0.1:4200?bind=:4201&passphrase=abcdefghijk&cryptomode=2" --sendrate 1Mbps --duration 60s --enable-metrics

(route and corrupt packets, branch develop/corrupt-packet)
./srt-xtransmit.exe route -i udp://127.0.0.1:4201?bind=:4200 -o udp://127.0.0.1:5200 --bidir --corruptfreq 5s

./srt-xtransmit receive "srt://:5200?passphrase=abcdefghijk&cryptomode=2" --enable-metrics -v

[ethouris]

I personally think it would be better to have a general mechanism of periodic log suppression, and I think some of such ones are already in use. My idea is to use a variable that remembers the time when the log was printed and a bit set that marks the message being printed. The bit set will be assigned to a particular type of message that should be printed often. The first message printer that catches the time counter to exceed the required suppression period, clears all the flags, which should be set always after the particular type of message has been printed. In order to avoid locking, the time counter and flag set should be affined to a particular thread.

[maxsharabayko]

It would be nice to have a general mechanism of periodic log suppression. A proper approach would require improving the logging facility.
It should have some buffer to store messages. It should be able to drop duplicated messages. And print a buffered message by timeout.

A simpler way is to add the general mechanism can be added using the introduced SRT_LOG_SLOWDOWN_FREQ_MS and m_tsLogSlowDown.
An additional variable with bitflags would also be needed to detect which logs should be affected like you suggest @ethouris .
Then on the next related LOGC both timestamp and bitflag are checked. If the time elapsed or the related bitflag is not set, then m_tsLogSlowDown is updated and the bitflag is set.
I guess updating m_tsLogSlowDown should not drop bitflags for other messages.
This mechanism would be quite clumsy and not that accurate, but simple.