The pair recheck on timeout can easily cause repetitive rechecks in
a ping-pong effect, if both peers with the same behaviour try to
check the same pair almost simultaneously, and if the network rtt
is greater than the initial timer rto. The reply to the initial
stun request may arrive after the in-progress conncheck
cancellation (described in RFC 5245, sect 7.2.1.4). Cancellation
creates a new stun request, and forgets the initial one.
The conncheck timer is restarted with the same initial value,
so the same situation happens again later.

We prefer a make a unique recheck per pair to avoid this bouncing
effect. Another workaround could be a avoid resetting the timer in such
situation. After enough retransmissions, the timeout delay, that doubles
after each timeout, becomes longer than the rtt, and the stun reply can
be handled.  The problem with this workaround is that a given stun
request may not be given enough individual retransmissions. If we
reset the number of retransmission while keeping the rto value, this
may lead to insanely long timeout values.

So the proposed strategy to make a unique recheck seems a good
compromise.

Differential Revision: https://phabricator.freedesktop.org/D1115