Fix errors with multi-process workers on Windows

[chadrik]

Fixes #21484 "Failed to write with error: 233" on Windows.

This change creates parity between Windows and POSIX, by not applying a server's connection timeout to the read/write traffic that follows on Windows.

Problem

An IPCServer's timeout applies to accepting a connection. On POSIX it stops there, because it is set on the listening socket and accept() hands back a blocking one, but on Windows it applies to the pipe handle and so also bounds every subsequent read and write. Once a peer is connected, the peer may legitimately stay silent for a long time while it computes, so this makes Windows give up on perfectly healthy peers.

After a build worker sends its setup ack it blocks in receive() waiting for the graph, but the coordinator only broadcasts the graph once it has finished loading it, which routinely takes longer than WORKER_CONNECTION_TIMEOUT on a large or cold-cache build. The worker's read fails with "Bad result from I/O wait: 258" (WAIT_TIMEOUT), main() swallows it, and the worker exits 0. When the coordinator finally broadcasts, every write thread dies looking for a pipe with nobody on the other end:

    Exception in thread Thread-7 (write_bytes):
      File "mypy/ipc.py", line 158, in write_bytes
    OSError: [WinError 233] No process is on the other end of the pipe
    ...
    mypy.ipc.IPCException: Failed to write with error: 233

and the following wait_ack() reports "Worker 0 disconnected before sending data (exit code 0)".

Solution

Split the timeout used by reads and writes from the one used to connect, and have IPCServer clear it, which is what POSIX already does. IPCClient keeps applying it to reads and writes, also matching POSIX, where it is set on the connected socket -- "dmypy hang" relies on that.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[ilevkivskyi]

Nice! I just have couple style comments (if you don't have time, I can apply them myself).

[ilevkivskyi]

This name is a bit misleading. It looks like it would affect POSIX as well. I think it is better to call this win_io_timeout.

[ilevkivskyi]

Two things here: move this under an if on the next line, then delete the comment below and combine it with this one and simplify. For example:

        # Unlike the client, a server applies its timeout only to accepting a
        # connection, never to the traffic that follows: see __enter__() below.
        # On POSIX this happens naturally after the sock.accept() call. On
        # Windows we need to set this manually to ensure equivalent behavior.