Stale socket notifications can be emitted to new sockets

Following QTBUG-82776 it is shown that, sometimes, notifications meant for sockets that are now closed are still left in the queue. This is documented[0] and usually it is not a problem since we will discard the events the next time the event-loop is spun. When the event-loop is not spun Windows could reuse the old socket descriptor for a newly created socket (in the related bug-report I could usually reproduce locally after 10-20 runs).

So, steps:

1. Create socket
2. Use socket
3. Close socket (generates a close notification)
4. Create new socket (and it ends up assigned with the socket descriptor from the first socket)
5. Spin the event loop to deliver the stale socket notification
6. The new socket handles it, some side-effects depending on the notification
   1. e.g. a close notification will try to read data, if no data is available it will disconnect

A possible way this could be fixed would be to somehow remove the related notifications once the socketnotifier is unregistered, but it's not that easy. PeekMessage only shows the first message of a certain type, that means if there are multiple socketnotifiers then if the first message is not related to the current socketnotifier being unregistered then there's no way to access the rest. Removing and requeuing all of them is likely not an option.

[0] https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsaasyncselect#remarks