Fall back from an unconfirmed nomination

[fergusean]

Description

controllingSelector.ContactCandidates resends the USE-CANDIDATE check to
the nominated pair on every tick until it succeeds. If every response to
that check is asymmetric, nothing ever fails the pair over, so the agent
stays "checking" until the connection times out even though other valid
pairs exist.

Observed with WebKit on macOS: a peer with two NICs on one subnet, bound
to the wildcard address, answers a nominated pair from the other
interface. Both pairs pass their own connectivity check individually,
but the nomination's own response is asymmetric and is correctly
discarded, with nothing else to end that nomination.

Fix

RFC 8445 §7.2.5.2.1 requires that an asymmetric response fail the check
it answers. Applied to the nomination case:

• Fail the nominated pair over on an asymmetric response to its own
  nomination, but only when another nominatable pair exists, so a lone
  pair (e.g. against an ICE-lite peer) is never stranded.
• Order binding requests with a per-agent, atomically assigned sequence
  number. A response to a request sent before the pair was abandoned is
  discarded; one sent after is always accepted, however the pair is
  later revived (re-arm, a role-conflict retry, a role switch, ...).
• Exclude renomination requests from that cutoff: the public
  RenominateCandidate API can claim a sequence number off the agent's
  task loop, so a paused renomination call could otherwise be discarded
  as stale even though it's concurrent with, not older than, the
  abandonment.
• RFC 8445 §7.3.1.4: a Binding request for a Failed pair re-arms it and
  sends a triggered check, instead of leaving it Failed forever.

Known limitations

• Binding requests here don't record their own local candidate, so a
  response can be attributed to the wrong local candidate of the same
  network type if another pair to the same remote exists. main
  records the request's source and doesn't have this gap.
• The controlling and controlled agents can end up with different
  selected pairs after a fallback, since the controlled side doesn't
  always follow a later nomination. pion's data-plane delivery isn't
  gated on the selected pair, so this is usually harmless.
• RenominateCandidate's off-loop access to the pending request list is
  a pre-existing data race, independent of this fix.

Tests

• Asymmetric nomination responses fail the pair over when an
  alternative exists, and are retried forever when none does.
• Stale and out-of-order responses (pre-abandonment retries, a
  different pair sharing an address, normal retry exhaustion, a
  role-conflict retry, a role switch and back) are handled correctly.
• Renomination responses are never mistaken for the current
  nomination's own response, including when addresses coincide.
• The request sequence counter is safe under concurrent, off-loop
  claims from RenominateCandidate, verified under -race.
• The RFC 8445 §7.3.1.4 re-arm sends exactly one triggered check.

🤖 Generated with Claude Code

[Sean-Der]

Closing for #1020