jdk-connector treats read timeout as a response timeout

The jdk-connector respects the client config option for read timeout, but it doesn't treat is as a socket read timeout (which the default connector does [^so_timeout], it applies it to reading the response as a whole. I can see if applying the read timeout to a response timeout field, which is set[^schedule] once the response has been parsed and the response body starts being processed.

I hit the issue when trying to GET a large entity using the jdk-connector ( See also #5470 )

I guess the bug is two things:

* The read timeout needs to be applied closer to the original semantics of a synchronous read timeout. I guess the response as a whole would fail if someone is blocking on the request and there's no activity on the socket for a certain amount of time?
* The response timeout should be set via a clearly marked setting, e.g. `RESPONSE_TIMEOUT` :)

[^so_timeout]: See org.glassfish.jersey.client.internal.HttpUrlConnector.class#_apply:L379
[^schedule]: Happens in org.glassfish.jersey.jdk.connector.internal.HttpConnection.class#handleHeaderSent:L145