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:

• Screen shares with mostly static images, 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)
• The reported timestamps 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.
• Stat reports may stall for more than one second: sometimes the same number of packets is reported two or more 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. However, in some cases it was observed that the reported packets may be repeated three times in a row, which would cause the connection to be flagged as very bad when the third value is received.
  Due to that the threshold should be increased from two to three reports in a row (four would be probably too much, although it may need to be adjusted again in the future, we will see). Of course this has the drawback of taking a bit longer to show the connection warning in the cases where no packets were actually sent, but in this case that is probably better than a false positive.