Suggested fix on Windows: handle also WSAETIMEDOUT after recv() returns failure

[Tor Lillqvist]

I have been debugging an interesting problem in Evolution's use of
GnuTLS on Windows. The root cause for the problem was elsewhere, see
below if you are interested. From GnuTLS's point of view the
interesting effect was that the recv() call in _gnutls_read() in
gnutls_buffers.c returned -1, with WSAGetLastError() returning
WSAETIMEDOUT. I think WSAETIMEDOUT should be handled like
WSAEWOULDBLOCK here? At least in this case, doing that made the code
work also without fixing the root cause.

FYI: The root cause for the problem was that libsoup uses setsockopt's
SO_RCVTIMEO and SO_SNDTIMEO options to set the socket's timeout,
passing a pointer to a struct timeval, like on Unix. But... the
Winsock designers, for some reason, decided to change the semantics of
these options: In Winsock the option value is an int, the timeout in
milliseconds. So when libsoup tried to set the timeout to 30 seconds,
it actually set it to 30 milliseconds, eek.) What on Earth were they
thinking when they changed the type of the option value for
SO_RCVTIMEO and SO_SNDTIMEO like this? They should at least have used
a different names for the options when they change the type of their
values. The type unsafety of setsockopt() means the compiler can't
warn either.

There must be something in the water in Redmond, one thinks.

--tml