Fixes #7043.

Summary

S3FileSystemProvider.newInputStream() previously returned the raw ResponseInputStream<GetObjectResponse> from the AWS SDK. When a caller closed the stream without having read it to EOF (e.g. path.withInputStream { readLine() }), Apache HTTP client's ContentLengthInputStream.close() would drain the remaining response body to release the connection back to the pool. For a multi-GB S3 object this blocked the caller for many minutes. On a small head node (e.g. 2 vCPUs) the blocked actor thread serialised the pipeline, producing a completely silent gap of tens of minutes in the log (only TaskPollingMonitor dumps every 5 minutes).

Fix

Wrap the returned stream so that close() calls ResponseInputStream.abort() on the underlying stream instead of triggering the Apache drain. The AWS SDK v2 ResponseInputStream exposes abort() exactly for this case (close the HTTP connection without draining).

Test

Adds S3InputStreamAbortTest — a regression test against the public ~1GB FASTQ at s3://ngi-igenomes/test-data/sarek/SRR7890919_WES_HCC1395BL-EA_normal_1.fastq.gz (anonymous, eu-west-1). The test reads the first line and closes on a background thread, bounded by Future.get(30s) (Spock's @Timeout/Thread.interrupt() cannot unblock a native SSL read, so the bound has to be on the caller side). Without the fix the close() drain blows the 30s timeout; with the fix the test completes in seconds.

Notes

This is a potentially user-visible semantic change: a caller that relied on close() to drain and discard the rest of the stream for connection reuse would now get an abort. In practice:

• Callers that consume the whole stream before closing are unaffected (reads still flow through the wrapper normally).
• Connection reuse still works — abort() closes the pooled connection instead of reusing it, which for an S3 NIO provider accessing arbitrary large objects is the correct trade-off.