[FEATURE] Split one huge event into multi small events to improve HDFS flush performance

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

### Search before asking

- [X] I have searched in the [issues](https://github.com/apache/incubator-uniffle/issues?q=is%3Aissue) and found no similar issues.

### Describe the feature

In current codebase, for huge partition, before it marked as huge partition,it will be reserved in the memory if having enough capacity. But when it is marked as huge partition, then it should be flushed into the HDFS, if this is specified.

In this first flushing process of this huge partition, it sometimes will be large, especially with the huge buffer capacity. And this will be slow because it is a huge flush event, which is not benifited from the concurrency hdfs partition writing mechanism.
And it will occupy memory space before this flush is finished, and will make the client backpressure.

From this point, the smaller flush event is better for shuffle-server throughout. But the local IO hope the big flush data buffer, which is a trade off.

Anyway, the huge partition huge flush event splited into multi small events to improve writing performance is useful.

### Motivation

_No response_

### Describe the solution

_No response_

### Additional context

_No response_

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

Start by tracing the huge-partition flush path in the Java codebase, focusing on the first HDFS flush and its interaction with concurrent partition writing and client backpressure. The issue does not name files or tests, so locate the relevant flush entry point first; done means large huge-partition flushes are split into smaller events while retaining the intended local-IO trade-off and improving HDFS writing performance.

Written by the indexing model from the issue text.