[Hudi-6318]The skip merge config for incremental-read ensures consistency in both stream and batch scenarios

[zhuanshenbsj1]

Change Logs

For example:

timeline: commit1, commit2, cluster1, commit3, commit4

I actually want to know what new data has been ingested upstream of commit2->commit4 through incremental reading in batch mode. If cluster1 is included, the old data belong to cluster1 will still be read once. If there are too many files, it will also have an invalid performance loss. So there should be an optional optimization option like stream mode

Impact

Describe any public API or user-facing feature change or any performance impact.

Risk level (write none, low medium or high below)

If medium or high, explain what verification was done to mitigate the risks.

Documentation Update

Describe any necessary documentation update if there is any new feature, config, or user-facing change

• The config description must be updated if new configs are added or the default value of the configs are changed
• Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
  ticket number here and follow the instruction to make
  changes to the website.

Contributor's checklist

• Read through contributor's guide
• Change Logs and Impact were stated clearly
• Adequate tests were added if applicable
• CI passed

[SteNicholas]

The read.streaming.skip_compaction and read.streaming.skip_clustering is the option of streaming read, not batch read.

[zhuanshenbsj1]

The read.streaming.skip_compaction and read.streaming.skip_clustering is the option of streaming read, not batch read.

We can add a similar batch configuration.

[hudi-bot]

CI report:

• 95bed13 Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build