Reapply graceful socket shutdown on Windows (revert 29992a6a509)

Hello

During the investigation of injection point test failures on
windows[1] we discovered that the issue causing the test failures was
already fixed, but reverted once, and that it seems safe to revert the
revert now.

On Windows, when a backend exits without closing its socket, the
kernel does an abortive close, which resets the connection, and the
client can lose unread data, including the FATAL message of a
terminated backend.

isolationtester only polls one connection at a time, so if it waits on
another session while a backend terminates, the error message is lost
and the permutation fails.

wait_cleanup (injection_points) and slot_creation_error
(test_decoding) failed randomly on the buildfarm because of this, and
e0f633ca6bc skipped them on Windows in all branches as a workaround.

The real fix was there in 2021 (6051857fc and ed52c3707:
shutdown(SD_SEND) + closesocket() in socket_close()), but 29992a6a509
reverted it, because walreceivers did not reliably notice
walsender-initiated connection close with it.
a8458f508a7 later fixed lost FD_CLOSE events in WaitLatchOrSocket(),
and its commit message already mentions that this might allow us to
try graceful shutdown again.

I did extensive local testing, and I was able to reproduce the
walreceiver failure with both 29992a6a509 and a8458f508a7 reverted,
but not with only reverting 29992a6a509.

Based on this, and the earlier discussion already in [1], I think we
should try reverting e0f633ca6bc (the windows specific test fix) and
29992a6a509 (the revert of the proper fix) on master, so that we can
watch the buildfarm and see if my analysis is correct.

The attached patches are simple clean reverts of these two commits.

[1] https://postgr.es/m/CAN4CZFO+KF=cc0-iEg28RhqRBp_fTs6D4b8b7D7DB-pGYP3Ccg@mail.gmail.com