connection_lost in individual StunProtocol triggers global ConnectionError (falsely causing DTLS handshake failure in aiortc) #101
Description
Multiple CandidatePairs are generated when setting up a Connection. In my particular setup, one of said pairs included a Link-Local local address, which understandably leads to a [Errno 65] No route to host when attempting to connect to the outside.
This ends up triggering StunProtocol.connection_lost to put (None, None) on the Connection's receive queue.
Simultaneously, a different CandidatePair manages to succeed. aiortc's RTCDtlsTransport begins it's SSL handshake and in the SSL.WantReadError codepath a transport._recv() ends up pulling the (None, None) from the queue which aioice raises as a ConnectionError.
I suspect other codepaths can potentially also trigger this, as far as I can tell if other paths are alive-and-well ConnectionError shouldn't be propagating.
Patch is probably as simple as not raising the ConnectionError if it's origin is not the current _nominated, but wasn't quite sure of other downstream implications of that, happy to make a PR if that's correct though.