Fix S3InputStream's handling of large skips

[alexjo2144]

Description

When the skip(n) method is called the MAX_SKIP_BYTES check is skipped, resulting in the call potentially blocking for a long time.

Instead of delegating to the underlying stream, set the nextReadPosition value. This allows the next read to decide if it is best to keep the existing s3 object stream or open a new one.

This behavior matches the implementations for Azure and GCS.

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

## Section
* Fix some things. ({issue}`issuenumber`)

[alexjo2144]

I was able to reproduce this issue, but not in a way where it's going to be easy to write a regression test. What I did was upload a 10GB uncompressed JSON file to s3 and set up the TextLineReader to read a small split. Before this change that reader took much longer to load a split at the end of the file than it did at the start of the file. After this change it is constant regardless of the split's start offset.

[wendigo]

I'm testing this with secrets now

[findinpath]

resulting in the call potentially blocking for a long time.

What is the furher consequence of this?
Please enhance the original description of the issue.

[wendigo]

@findinpath I think that existing description is exhaustive enough. For S3 FS any delayed request will cause planning/execution to be longer than necessary.

[wendigo]

@alexjo2144 thanks, merging