React to DNS changes according to progress

Do not restart or cancel established work just because the waiting list changes.

• While connection establishment is in progress, DNS answers can add or remove candidates, for example through updates or TTL expiry. The client should react based on whether a destination was already attempted, is still waiting, or a connection has already won (§6).
• If a removed address already has a started attempt, that attempt SHOULD NOT be cancelled merely because the DNS answer removed it. In the chosen policy V6-A can remain pending after removal; normal success/failure still decides its result (§6).
• If the removed address was not attempted, it SHOULD be removed from the waiting list. Starting a previously scheduled attempt for that removed waiting candidate would defeat this policy. The helper removes it without inventing a successful connection (§6).
• New addresses should be sorted into the not-yet-attempted list according to §4. The helper accepts a newly ranked waiting list and interleaves that list; it does not restart active attempts or reset their elapsed times. A late AAAA after the short resolution wait can therefore join the race before success (§§3,6).
• After a winner, new candidates are not used for that connection (§5). If all started attempts fail and the waiting list is empty, the chosen model reports no established connection rather than fabricating a winner. DNS retries, future application retries and final error reporting are outside this small state model.