[Feature] Support blob.split-by-file-size to weigh blob files in scan splitting

[SteNicholas]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Java Paimon provides the blob.split-by-file-size option (no default value, see CoreOptions.BLOB_SPLIT_BY_FILE_SIZE in apache/paimon) to control whether blob file size is considered as a factor when performing scan splitting. When unset it derives from the negation of blob-as-descriptor: content reads count blob file sizes, while descriptor reads (which never fetch blob payloads) weigh a blob file only by the open file cost.

paimon-cpp currently has no such option: the weight function in DataEvolutionSplitGenerator::SplitForBatch unconditionally sums file_size of every file in a row-id range, including .blob files. This matches the Java default for content reads, but there is no way to opt out. Under blob-as-descriptor reads, where only ~100-byte descriptors are materialized, the huge blob file sizes still dominate split weights and shatter the scan into many tiny splits, leaving a behavior gap between the two implementations.

Solution

Align with the Java implementation:

• Add Options::BLOB_SPLIT_BY_FILE_SIZE ("blob.split-by-file-size", no default) and parse it into CoreOptions together with blob-as-descriptor, exposed as CoreOptions::BlobSplitByFileSize() which returns the explicit value or falls back to the negation of blob-as-descriptor (matching CoreOptions#blobSplitByFileSize).
• Add a count_blob_size flag to DataEvolutionSplitGenerator: the split weight function counts a blob file as its file_size when enabled, otherwise as the open file cost, while non-blob files always count as file_size (matching DataEvolutionSplitGenerator#splitForBatch).
• Pass CoreOptions::BlobSplitByFileSize() when constructing DataEvolutionSplitGenerator in the data-evolution scan path (matching AppendOnlyFileStoreTable#splitGenerator).
• Tests: CoreOptionsTest assertions for the default, the value derived from blob-as-descriptor, and explicit-value precedence; a SplitGeneratorTest case verifying that the same data/blob file layout packs into different splits depending on the flag.

Anything else?

The option key, default derivation, and weighting semantics follow CoreOptions.BLOB_SPLIT_BY_FILE_SIZE and DataEvolutionSplitGenerator in apache/paimon (introduced in apache/paimon#7020).

Are you willing to submit a PR?

• I'm willing to submit a PR!