It turns out that Windows have a special behaviour WRT cancelling asyncs for terminating thread (or already terminated thread when socket handle is closed) when there is no more open handles in the process for the socket (while there might be handles to it in another processes).
We currently have a logic on cancelling async in server/async.c:cancel_terminating_thread_asyncs() called before thread termination. It has a special case ("async->completion && async->data.apc_context && !async->event") when async is not canceled (covered by the tests). It turns out that on Windows, if there are no more handles to the socket in the async's process, async is cancelled even in this case.
Then, if thread is terminated while there are open handles in the same process, but those handles are closed after that, it turns out the asyncs should be canceled the same way, even if there are handles for the socket in another process.
Why this is important (and, actually, makes some sense to me), is that it is very easy to duplicate all the open handles to the child process. Just e. g., Qt doesn't seem to have any way to create a process through QtProcess without inheriting handles. Programs might expect that once they close socket handle the async operations will be aborted and they receive completions on port. But that doesn't happen if they didn't use an event for overlapped operation and happened to create any child process with inherited handles after creating the socket. Windows behaviour looks to me as a workaround for this.
Besides the present test, I also tested the same with AcceptEx and IOCTL_AFD_RECV which behaves the same. Just to note, closing the handle before thread termination when there are no other open handles is quite a different case. In its heart it behaves *somewhat* similar on Windows and Wine but not quite, hitting various issues. But that looks unrelated to the special case concerned in this patchset.
Fixes Battle.net hanging on exit during "update and restart" (not to confuse with update itself not finishing which is an unrelated issue related to file DACLs).