[FLINK-38569][table-planner] Avoid generating ReadingMetadataSpec when no metadata

[fresh-borzoni]

closes https://issues.apache.org/jira/browse/FLINK-38569

The purpose of the change:

• Prevented creation of no-op ReadingMetadataSpec instances when the computed metadata key set is empty.
• Updated planner logic to only create ReadingMetadataSpec when at least one metadata key is actually required.
• Updated existing planner golden tests to remove metadata=[] digests, which were produced solely due to empty metadata specs.

Verification:

• Updated/added planner rule tests (golden plans) covering the affected rules

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

[flinkbot]

CI report:

• 0622594 Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[fresh-borzoni]

FLINK-38569 is about removing no-op ReadingMetadataSpec instances (metadata=[]), which are planner artifacts with no semantic effect, so it causes confusion.

During implementation it became clear that unconditionally skipping metadata handling would regress FLINK-23911, which relies on invoking SupportsReadingMetadata.applyReadableMetadata(...) even when the effective metadata set is empty, to correctly configure source output schemas.

This change therefore separates these concerns:

• source configuration (applyReadableMetadata) is preserved, including for empty metadata sets
• ReadingMetadataSpec is created only when metadata is actually read

This avoids no-op planner abilities while maintaining existing source semantics.
The separation is intentional but open for discussion if this coupling is still preferred.