agent: verify the best nominated pair after priorities recalculation

When we get a set_remote_candidate late after the start of the conncheck, some remote candidates type may change from peer-reflexive to server-reflexive. This required a recalculation of the foundations and of the priorities of the related pairs.

This recalculation may change the pairs ordering in the conncheck list: a srflx:prflx pair becoming a srflx:srflx pair will have a lower priority (RFC 8445, section 5.1.2.1 "Recommended Formula", "the type preference for peer-reflexive candidates MUST be higher than that of server-reflexive candidates.")

This recalculation is required to maintain the same pairs ordering in both agent.

But in some cases, in aggressive nomination mode, this may also change the nominated pair, if this recalculation changed the highest priority pair with the nominated flag.

This unusual case has been detected by tweaking telepathy-farstream to make it send each local candidate individually with a random delay, and in farstream also by randomly delaying the calls to nice_agent_set_remote_candidates() and nice_agent_set_remote_credentials(). libnice remains quite robust in this case, even when both peers are "tweaked" this way. It starts the conncheck with partial information, and recovers when bits of data arrive later.

Update: I fixed some indentation in nice_debug() in a supplementary patch.

Update2: I renamed the function name from priv_update_nominated_pair() to priv_update_selected_pair(). I also updated the prflx_priority value.

Update3: I added a third patch that also update the priority of the selected pair if the selected pair is concerned by the effect of a remote foundation update.

Update4: In a 4th patch, I refactored the code in priv_update_selected_pair() that was mostly similar to the same function in conncheck.c. The only difference being that selected_peer.priority must be up-to-date in version from conncheck.c.