Fix (known) false positives in connection warning

[danxuliu]

Fixes (non-UI part of) #14019

There are some known false positives that cause the connection warning to be shown when the connection is fine:

• Stat timestamp may not be updated when the stats stall: sometimes the same number of packets is reported two times in a row. The code currently keeps the quality calculation on hold if the same number of packets is reported twice in a row until a third value is received, and then updates the quality based on that third value. In the past it was observed that when the stats stalled the timestamps were updated. However, it seems that it can also happen that the timestamp is also repeated, which messes with the calculations and causes the connection to be reported as very bad even if the same number of packets is reported twice in a row (which was expected to be correctly handled already, but due to this new finding turns out that it is not).
  • Fixed by evenly distributing the timestamps when they stall
  • This seems to be exclusive of Firefox, as Chromium does not provide a packetsReceived value in remote-inbound-rtp.
  • It is unclear whether the stats can stall more than two times in a row. It was assumed that the connection warning was caused by that, but it is most likely that the stalled timestamp was the actual problem and that it was mistakenly identified as the stats stalling three times in a row. For now it will be assumed that if the same stats are repeated three times in a row there is a connection problem, and it will be adjusted in a follow up if it is found out that it is a false positive.
• Videos with mostly static images and low information (like a blurred background with the video quality reduced due to being in a call with several participants), which may send even less packets per second than the current threshold (10) used to mark the connection as very bad (and therefore show the connection warning)
  • Workarounded by no longer showing a connection warning to the user when the packets per second are low; further investigation would be needed, but in any case it seemed to cause more false positives to be reported than actual positives
• The reported packet count may "go back in time" to a previous value (it seems to happen when enabling the video, but it is not reproducible at will), which messes with the quality calculation.
  • After endless tests it was not reproducible once... It was just found in provided logs, so a "synthetic" test was added that reproduces what was seen in those logs and the issue was fixed by resetting the stats when the received packet count regresses.
  • Although the issue from the logs could not be reproduced a similar (but not fully matching) issue was also found: due to a bug in Firefox and/or Janus (the stats overflowing is a bug in Firefox and even the spec, but in theory it should not happen unless it received invalid values from Janus) the received packet count may overflow. This typically happens in the stats of the lower quality stream of a simulcast video.

Follow ups

• Fix distribution of staged stats (as right now they can be distributed when the values are staged three times due to a wrong if (packets > 0) { condition)
• Maybe log stats returned by getStats() and not only the processed values in case of strange scenarios (like the packet count regressing) to try to better understand it

[nickvergessen]

Reviewable soon?

[danxuliu]

/backport to stable31

[danxuliu]

/backport to stable30

[danxuliu]

/backport to stable29

[Antreesy]

Thanks for detailed comments!
Smoke tested in local call with blurred bg and screenshares, haven't received any warnings, as was noticed before for these cases