[SUPPORT] Schema Evolution in MR Reading of Hudi Causes Metadata List Request for Each Split

**_Tips before filing an issue_**

- Have you gone through our [FAQs](https://hudi.apache.org/learn/faq/)?

- Join the mailing list to engage in conversations and get faster support at dev-subscribe@hudi.apache.org.

- If you have triaged this as a bug, then file an [issue](https://issues.apache.org/jira/projects/HUDI/issues) directly.

**Describe the problem you faced**
[HUDI-5000](https://issues.apache.org/jira/browse/HUDI-5000) introduced schema evolution for Hive reading Hudi tables, causing the HoodieParquetInputFormat to create a metaClient for each split. Constructing a metaClient requires listing the Hudi table metadata directory, which puts significant pressure on the HDFS NameNode when there are a large number of splits.

If the user is certain that there will be no schema changes, this overhead is unnecessary. Although the current implementation supports controlling schema evolution via the hudi.hive.schema.evolution parameter, it does not skip schema evolution when this parameter is explicitly set to false. Consequently, the metaClient is still created, and the metadata directory is listed.

I propose that when hudi.hive.schema.evolution is explicitly set to false, the construction of the metaClient should be skipped. This way, the doEvolutionForRealtimeInputFormat method would return immediately if the internalSchemaOption is empty, avoiding unnecessary metadata directory listing.

I am looking for suggestions or best practices on how to optimize this process. Specifically, I would like to know if there are any strategies or configurations that can reduce the number of list requests initiated during split reads while schema evolution is enabled.


**To Reproduce**

Steps to reproduce the behavior:

1.
2.
3.
4.

**Expected behavior**

A clear and concise description of what you expected to happen.

**Environment Description**

* Hudi version :

* Spark version :

* Hive version :

* Hadoop version :

* Storage (HDFS/S3/GCS..) :

* Running on Docker? (yes/no) :

**Additional context**

Add any other context about the problem here.

**Stacktrace**

```Add the stacktrace of the error.```

Start with HoodieParquetInputFormat and the doEvolutionForRealtimeInputFormat method, then review the schema-evolution behavior introduced by HUDI-5000. Check how hudi.hive.schema.evolution is parsed when explicitly false and verify whether the metaClient and metadata-directory listing are skipped; add or update coverage for this path if the relevant tests are found.

Written by the indexing model from the issue text.