Behavioral change of shutdown() in Linux > 6.1.32

[rlebeau]

Apparently, a recent change in Linux now prevents one thread from disconnecting a TCP socket if other threads are waiting on the socket!

This does not bode well for Indy, which expects to be able to shutdown/close a TCP socket while threads are blocked on socket I/O operations. For #3 and #491, this change means that using connect() in non-blocking mode now becomes more important, otherwise ConnectTimeout becomes useless as a blocked connect() will no longer unblock when shutdown() is called.

Need to review if other socket functions now have potential problems introduced by this change in behavior.

[kralo]

judging only by reading, have not tested yet, this linux commit ("tcp: allow again tcp_disconnect() when threads are waiting") torvalds/linux@419ce133ab928ab5efd7b50b2ef36ddfd4eadbd2 might make changes obsolete. Looks like .NET also depended on it

[rlebeau]

Even so, changing Indy to handle connects with timeouts better still has merit. But there are other aspects of Indy that would still be affected by this Linux behavior, such as TIdTCPServer shutting down while its client threads are blocked on pending reads. So hopefully this reversal in Linux's behavior will preserve that ability.