feat(cache): support parquet metadata cache

[gripleaf]

Purpose

Support caching parsed Parquet FileMetaData to avoid repeatedly reading and parsing Parquet footers when creating readers for the same file.

This change:

• Adds ParquetMetadataCache, backed by GenericLruCache.
• Adds option parquet.read.metadata-cache.max-bytes.
• Initializes one metadata cache per ParquetReaderBuilder when the configured size is greater than 0.
• Uses cached metadata in ParquetFileBatchReader::Create through Parquet FileReaderBuilder::Open(..., file_metadata).
• Keeps cache entries keyed by file URI.

Tests

Added/updated UT cases in parquet_file_batch_reader_test:

• TestReadRewrittenFileWithoutMetadataCache
• TestMetadataCacheGetOrLoad
• TestMetadataCacheNullLoaderResultIsNotCached

Not run locally: full CMake build/tests, because the local build blocks on bundled Arrow/Boost dependency download.

API and Format

No storage format or protocol changes.

No public include/ API changes.

Adds a Parquet read option:

• parquet.read.metadata-cache.max-bytes

Documentation

This introduces a new Parquet reader optimization. No standalone documentation changes are included.

Generative AI tooling

Generated-by: OpenAI Codex GPT-5

[lxy-9602]

I’d like to better understand in what scenarios the same file would be read multiple times. As far as I remember, the code only has prefetch-related optimizations, and prefetch should already open files concurrently. In that case, how much can the metadata cache realistically reduce read latency? Do we have any concrete data showing that the Parquet footer is a bottleneck and that this optimization provides a meaningful latency improvement? Perhaps this is mainly beneficial for extremely wide tables with a large number of fields?

[gripleaf]

We provide online services on top of Paimon, primarily focused on point lookups and short scans, and we might disable the prefetch feature (to avoid wasting bandwidth on prefetching). I understand that the current paimon-cpp may be more geared towards offline analytics scenarios.

[gripleaf]

we also need offline analytics now, I means this features is focus on our online serving scenarios.

[lxy-9602]

Because captures in std::function may introduce some memory issue, I’d suggest preferring pass-by-value over const Func&.

[lxy-9602]

I wanted to confirm one point about the Parquet footer: in point lookup, is the footer becoming a performance hotspot because of parsing or because of I/O? If it is mainly I/O, could we handle it similarly to how we cache manifests? The cache added in ReadContext does not seem to be used yet. If the bottleneck is parsing, then we could consider caching a ::parquet::FileMetaData object instead. That said, this optimization feels somewhat specialized and would be more intrusive to the codebase, so I think we should first confirm that the performance benefit is large enough.

[gripleaf]

cache parquet footer bytes in #373 , close this PR