SQL: Fix issue with timezone for JDBC pagination

[matriv]

Previously, when the specified (or default) fetchSize led to
subsequent HTTP requests and the usage of cursors, those subsequent
cursor requests didn't use the timezone defined in the connection
properties. Even though the query is executed once (with the correct
timezone) the processing of the values returned by the HitExtractors
in the next pages was done using the default timezone Z. This could
lead to incorrect results.

Fix the issue by passing the initially configured timezone to each
subsequent cursor HTTP request.

Add a note in the docs to clarify that when the REST endpoint is used,
the user needs to keep passing the time_zone parameter to each
subsequent request, as there is no notion of a user session through in
the REST HTTP endpoint.

Relates to: #51258

[elasticmachine]

Pinging @elastic/es-search (:Search/SQL)

[matriv]

@elasticmachine run elasticsearch-ci/packaging-sample-matrix-windows

[costin]

Even though the query is executed once (with the correct
timezone) the processing of the values returned by the HitExtractors
in the next pages was done using the default timezone Z. This could
lead to incorrect results.

That's a bug - the HitExtractors are serialized in the cursor using the initial timezone - it's a bug to not use that timezone which is available from the stream (SqlStreamInput).
Sending any timezone in a pagination request is a bug - it can either be redundant (we already know about it) or different (what do we do then); we should check that and throw an exception if that happens.
We already have all the information we need, the onus is on us to preserve it around.

[matriv]

Closing this as the approach was incorrect.
Thanks @costin for helping out!
Opened #52101 instead, which fixes the bug, and no doc update is required.

[ywelsch]

Please remove version labels when closing a PR, as these are used to drive release notes