Ensure that underlying resources of the parquet reader are closed

[findinpath]

Description

Release the underlying resources after reading the number of records from the Parquet file.

Is this change a fix, improvement, new feature, refactoring, or other?

Fix.

Is this a change to the core query engine, a connector, client library, or the SPI interfaces? (be specific)

Delta Lake connector.

How would you describe this change to a non-technical end user or system administrator?

Before this change, the underlying AWS client library which was accumulating “leased” connections after each UPDATE statement performed via delta-lake connector. This sounded like a connection leak.
The current change makes sure that the underlying resources after reading the number of records from the Parquet file
via AWS S3 API are being closed. In this manner, the leased connection is being released.

Related issues, pull requests, and links

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

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

[jirassimok]

Looks good to me. The only thing I'd change is that if we're changing a line that's this long, I'd prefer we also find a way to wrap it a bit (maybe just split the line after open().

[findepi]

Is this the only one?

perhaps we could have a s3 max open connections setting in aws smoke test to some low value -- reproducing the problem, and ensuring the fix, and guarding against regressions

[findinpath]

Is this the only one?

I looked through the source code for the usages of filesystem create ... / open ... operations which deal with streams and found out that they were using all try-with-resources pattern.

perhaps we could have a s3 max open connections setting in aws smoke test to some low value -- reproducing the problem, and ensuring the fix, and guarding against regressions

@findepi I will modify the aws smoke test to take your suggestion into consideration. Thanks for the suggestion.