Improve consent freshness robustness
With this patch we improve consent freshness RFC7675 bahaviour:
- we use regular keepalive stun binding requests, with their regular retransmission properties, just the delay between two stun requests is modified when consent-freshness is enabled (vs regular keepalives)
- the global consent timeout is computed based on the number of time a keepalive remains unreplied. Compared to regular keepalives, it is expected to improve robustness by allowing several consecutive stun request to be lost, before declaring the component failed.
- losing consent for a component is accepted when the conncheck has a selected pair, ie when we're in state connected at least.
- the remote and local consent can be merged in a single flag
- when consent is lost, the local component must transition to state failed, so the state is the same for both peers.
- the transition from state ready to failed cannot be recovered, so we can safely delete the whole conncheck list in that case.
We use regular keepalives, because they are already based on stun binding requests, and they just work like other stun requests used elsewhere in libnice, depending on an initial delay, a fixed number of retransmissions, and an exponential retransmission delay. Moreover their emission scheduling takes care of the overall required pacing (ideally no more than a single stun binding request per 20ms), so the randomization of their emission to avoid bursts is not needed.
Edited by Fabrice Bellet