Add socket timeout integration tests

[rschmitt]

This change adds integration test coverage for various types of read timeouts. The test coverage includes HTTP, HTTPS, and HTTP over UDS if available. The /random request handlers have been augmented with delay support, so that the clients can read the response headers and then time out while reading the entity. The tests make use of ConnectionConfig, ResponseTimeout, and (on the sync client only) SocketConfig, and demonstrate the precedence among these config options when more than one is supplied.

One issue uncovered by these tests is that graceful closure of the async client does not work when UDS socket timeouts have fired. To work around this until the issue can be root caused, the async UDS tests use CloseMode.IMMEDIATE.

[rschmitt]

I was startled to learn that java.net.Socket::setSoTimeout only sets read timeouts:

https://github.com/openjdk/jdk/blob/d186dacdb7b91dc9a28b703ce3c8ea007fc450b6/src/java.base/share/classes/java/net/Socket.java#L1258-L1260

Given that this is the case, I'm not sure what prevents synchronous clients from going to sleep forever if a write blocks indefinitely because the send buffer filled up. Additionally, I haven't found a way to simulate this condition using localhost (at least not on macOS), so I can't even determine whether there's a sensible default value or something.

[ok2c]

I was startled to learn that java.net.Socket::setSoTimeout only sets read timeouts:

https://github.com/openjdk/jdk/blob/d186dacdb7b91dc9a28b703ce3c8ea007fc450b6/src/java.base/share/classes/java/net/Socket.java#L1258-L1260

Given that this is the case, I'm not sure what prevents synchronous clients from going to sleep forever if a write blocks indefinitely because the send buffer filled up. Additionally, I haven't found a way to simulate this condition using localhost (at least not on macOS), so I can't even determine whether there's a sensible default value or something.

@rschmitt In the older version of HttpClient the socket timeout used to be called SO_READ_TIMEOUT. This is yet another limitation of the classic i/o one must tolerate

[rschmitt]

This is yet another limitation of the classic i/o one must tolerate.

Yeah, this is probably one reason why virtually all server IO is non-blocking, even when the API is synchronous (see for example Tomcat).

[rschmitt]

I still need to look into this some more. Based on the logspam I get during IOReactor shutdown, it's some sort of low-level selector issue. Could be a behavioral difference with UDS SocketChannels.

[rschmitt]

@ok2c Anything else on this one?

[ok2c]

@rschmitt Not really. Looks good to me