GH-45092: [C++][Parquet] Add GetReadRanges function to FileReader

[zeroshade]

Rationale for this change

For some consumers, it is convenient to expose a way to retrieve the necessary byte ranges of a parquet file to read specific column chunks from row groups without having to go through a full ReadRangeCache. Ultimately, it's a fairly simple function since we already have all the infrastructure implemented to compute these ranges.

What changes are included in this PR?

A single function added to parquet::FileReader named GetReadRanges which computes and retrieves the coalesced read ranges for specified row groups and column indices.

• GitHub Issue: [C++][Parquet] Expose ReadRanges in Parquet FileReader #45092

[github-actions]

⚠️ GitHub issue #45092 has been automatically assigned in GitHub to PR creator.

[kou]

Could you also fix the lint errors?

I don't object this API but is there any conreate use-case of this API?

[lidavidm]

I pinged colleagues to give a review and make sure the API fits their use case. But essentially sometimes we want to accomplish pre-buffering (like ReadRangeCache) but without having to go through that API specifically. (Possibly it would work to implement a custom RandomAccessFile too?)

[wgtmac]

I think this is more like an utility function that users are capable of parsing parquet::FileMetaData to compute the same result on their end. In terms of the extensibility, if users want a third parameter of requested row ranges in addition to row group and column, do we want to support it as well?

FYI there was a discussion on the row range API: https://docs.google.com/document/d/1SeVcYudu6uD9rb9zRAnlLGgdauutaNZlAaS0gVzjkgM and a stale PR: #39731.

[mapleFU]

General looks ok to me ( but without page index, I think it might not prune many data)

[felipeblazing]

The idea is that we would like to be able to know ahead of time what bytes are going to be read from a parquet file without necessarily performing the computation associated with decoding the file at the same time. The high level use case for us is that sometimes we don't have the computational resources to perform decompression and decoding but we do have available I/O. We want to be able to continue to perform I/O when interacting with object stores and other slow sources of parquet data without having to commit to decompression / decoding until a later point in time.

This would allow us to move bytes from object stores to local memory where it can wait until we have compute resources for decompression / decoding.

[zeroshade]

Lint issues fixed and variable renamed as suggested

[mapleFU]

This patch LGTM now. Out of curiousity, why not call PreBuffer in SerializedFile, but call this new interface?