Add more connection TTL options to the Netty HTTP client

[millems]

Missing feature matrix:

Setting	1.11.x	2.0 (Sync, Apache)	2.0 (Async, Netty)
Connection TTL	clientConfig.setConnectionTTL(...)clientConfig.withConnectionTTL(...)	httpClientBuilder.connectionTimeToLive(...)	Not Supported
Connection Max Idle	clientConfig.setConnectionMaxIdleMillis(...)clientConfig.withConnectionMaxIdleMillis(...)	httpClientBuilder.connectionMaxIdleTime(...)	Not Supported
Validate After Inactivity	clientConfig.setValidateAfterInactivityMillis(...)clientConfig.withValidateAfterInactivityMillis(...)	Not Supported	Not Supported
Connection Reaper	clientConfig.setUseReaper(...)clientConfig.withReaper(...)	httpClientBuilder.useIdleConnectionReaper(...)	Not Supported

[Eyal-Shalev]

@millems is there a way to set the connection TTL on an async client without these functions?

[shorea]

These settings may or may not make sense for a NIO client. If a channel goes inactive it will remove itself from the pool as far as I know. Compare that to blocking IO where a connection may go inactive but we won't know that until the next time we use it, resulting in a failed request. Connection TTL makes sense for both. We should confirm the inactive behavior of channel before implementing the max idle, validate after inactivity, and idle reaper in NIO.

@Eyal-Shalev there is not a way to set connection TTL currently.

[JD557]

If a channel goes inactive it will remove itself from the pool as far as I know.

I don't think this is true. I'm having some issues with some code trying to call SageMaker with a long connectionMaxIdleTime/connectionTimeToLive.

The code worked fine on v1, but on v2 I notice that, if I make a request, wait ~1 minute and perform another request, I get an error:

java.util.concurrent.CompletionException: software.amazon.awssdk.core.exception.SdkClientException: Unable to execute HTTP request: Server failed to send complete response. The channel was closed. This may have been done by the client (e.g. because the request was aborted), by the service (e.g. because there was a handshake error, the request took too long, or the client tried to write on a read-only socket), or by an intermediary party (e.g. because the channel was idle for too long).

I assume that this is caused by SageMaker closing the connection, which is never revalidated and ends up being reused.