Aliyun, Dell: Handle EOF in OSS and ECS InputStream read() variants

[damansingh1313]

Why is this change needed?

OSSInputStream (aliyun) and EcsSeekableInputStream (dell) advance pos (and next, in OSS's case) and increment the readBytes/readOperations metric counters before checking whether the underlying stream has reached EOF (-1). When a read call actually returns -1:

• The tracked position is advanced by one byte (read()) or decremented by one byte (read(byte[], int, int), since -1 is added to pos/next), desyncing the stream's internal position bookkeeping from the real position in the object.
• The readBytes counter is incremented by -1 in the buffered-read path, producing a nonsensical negative byte count in read metrics.

S3InputStream, GCSInputStream, and ADLSInputStream already guard against this (fixed in #16055); OSSInputStream and EcsSeekableInputStream were the two implementations left over from that fix. This PR applies the same guard to both.

A previous attempt at this exact fix (#16266) was opened but auto-closed for inactivity rather than rejected on merit — this PR picks that up with tests added for both the single-byte and buffered read() overloads on each class.

Closes #16062

What user-facing changes does this include?

None. This only affects internal position tracking and read metrics inside OSSInputStream and EcsSeekableInputStream when a read reaches EOF; there is no change to any public API, table format, or configuration.

Are there any user-facing changes?

• Fixes metrics reporting a negative byte count when a buffered read hits EOF.
• Fixes internal position tracking so a stream that has hit EOF doesn't end up with a position off by one byte relative to the actual object length.

How was this change tested?

Added testReadSingleEOF and testReadBufferedEOF to both TestOSSInputStream and TestEcsSeekableInputStream, mirroring the tests added for S3InputStream/GCSInputStream/ADLSInputStream in #16055.
Verified locally that all four new tests fail against the pre-fix code and pass after the fix; ran spotlessCheck for both modules.

[damansingh1313]

Hi @anoopj @amogh-jahagirdar,
Please review.

[anoopj]

This test here doesn't exercise this fix. I think it might be passing even without the fix. This is because the single-byte path already returned -1 correctly pre-fix (return stream.read()). The only bug there is pos/next desync.

Consider adding a getPos() assertion:

assertThat(in.read()).isEqualTo(EOF);
assertThat(in.getPos()).isEqualTo(data.length);

This applies to the other testReadSingleEOF as well.

[damansingh1313]

Addressed, thanks for pointing it out — added the getPos() check to both tests.

[anoopj]

Code change LGTM. Left a comment on testing

[anoopj]

cc @amogh-jahagirdar for a review.

[damansingh1313]

cc @amogh-jahagirdar