[Feature][Connector-V2][HdfsFile] Support true large-file split for parallel read

[yzeng1618]

Purpose of this pull request

#10326
HdfsFile source currently uses “one file = one split”, which limits parallelism when there are only a few huge files.

Does this PR introduce any user-facing change?

yes

1. This PR adds enable_file_split / file_split_size to HdfsFile source and wires HDFS-specific split strategies:

• text/csv/json: split by file_split_size and align split end to the next row_delimiter (HDFS seek-based implementation for large files).

• parquet: split by RowGroup (logical split) and read footer metadata using HadoopConf-backed Configuration (works with Kerberos/HA/NameService).

2. Example:

enable_file_split = true
file_split_size = 268435456
row_delimiter = "\n" (for text/csv/json)

How was this patch tested?

1. Unit tests
   HdfsFileAccordingToSplitSizeSplitStrategyTest#testReadBySplitsShouldMatchFullRead

2. E2E
   HdfsFileIT#testHdfsTextReadWithFileSplit

Check list

• [ * ] If any new Jar binary package adding in your PR, please add License Notice according
  New License Guide
• [ * ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
• If necessary, please update incompatible-changes.md to describe the incompatibility caused by this PR.
• If you are contributing the connector code, please check that the following files are updated:
  1. Update plugin-mapping.properties and add new connector information in it
  2. Update the pom file of seatunnel-dist
  3. Add ci label in label-scope-conf
  4. Add e2e testcase in seatunnel-e2e
  5. Update connector plugin_config

[chl-wxp]

Suggested change

	public class HdfsFileAccordingToSplitSizeSplitStrategy implements FileSplitStrategy, Closeable {
	public class HdfsFileAccordingToSplitSizeSplitStrategy extends AccordingToSplitSizeSplitStrategy{

1、Modify AccordingToSplitSizeSplitStrategy to introduce HadoopFileSystemProxy
2、Delete LocalFileAccordingToSplitSizeSplitStrategy

[yzeng1618]

Okay, so you still suggest reusing the base code as much as possible? My main concern is that it might affect the logic of the localfile code.

[chl-wxp]

Okay, so you still suggest reusing the base code as much as possible? My main concern is that it might affect the logic of the localfile code.

Yes, the sharding logic should be maintained uniformly in the base, and there should not be a lot of code redundancy. It is also convenient to add this function to file system connectors such as S3 and OSS.

[chl-wxp]

Suggested change

	public class HdfsFileSplitStrategyFactory {
	public class FileSplitStrategyFactory {

Delete LocalFileSplitStrategyFactory

[chl-wxp]

Remove HdfsParquetFileSplitStrategy and enhance ParquetFileSplitStrategy