[python] Reuse Parquet fragment metadata for single-file reads

[XiaoHongbo-Hope]

Purpose

Reading a known Parquet data file through ds.dataset(path, ...) performs path discovery and loads metadata into separate objects. With the default metadata cache enabled, a local cold scan makes one get_file_info call and three open_input_file calls.

Create a ParquetFileFragment directly and build FileSystemDataset with that same fragment and its physical schema. This reduces the local cold scan to zero probes and two opens, while retaining the existing cache lifecycle, physical schema handling, and constructor for other formats.

Tests

• Added call-count regressions for cold/hot reads, disabled cache, eviction and concurrent scans. Verify that schema, footer metadata, row-group splitting and cache-size estimation reuse loaded fragment metadata without more I/O. Added missing/corrupt-file failure and retry coverage.
• 150 tests passed on Python 3.11 / PyArrow 19.0.1 after applying the change to current master: metadata cache, row ranges, VARIANT row groups, schema evolution, nested fields, predicate pushdown and row readers/writers.
• Repository-configured flake8, license-header checks and git diff --check passed. PyArrow 16.1.0 was unavailable and remains unverified.

Also ran a real DLF → Jindo 6.10.401 → OSS A/B with this loader change isolated. Used fixed snapshots and identical queries, files and read parallelism (4), with A-B-B-A process ordering and a cold/hot read in each process. All output hashes matched across 32 Parquet scans. Native successful-response logs accounted for 448 unique OSS request IDs.

Data-file requests per query	HEAD before → after	GET before → after
Four files, complete cold scan	12 → 8	12 → 8
Four files, complete warm scan	4 → 4	4 → 4
Cold scan with filter and nested projection	11 → 7	11 → 7
Metadata cache disabled, each scan	8 → 8	8 → 8

The complete-scan results held for both 1,024-row small-file and 16,384-row larger-file fixtures (each larger file exceeds 64 KiB). Counts cover data-file requests, excluding DLF metadata and manifest planning. They are specific to these fixtures and SDK settings; they do not establish a production QPS reduction. Temporary test tables were cleaned up.