[Load] Isolate reused TsFile parser memory from Pipe pool

[Caideyipi]

Description

Problem

Load reuses TsFile insertion parsers, whose tablet, chunk, page, and modifications blocks were hard-coded to PipeDataNodeResourceManager.memory(). A large Pipe tablet backlog could therefore consume the Pipe pool and prevent Load from acquiring query memory.

Fix

• Inject a parser memory owner through TsFileInsertionEventParserMemoryManager.
• Keep existing parser constructors on the Pipe pool for Pipe callers.
• Route Load tree scan/query and table parsing through LoadTsFileParserMemoryManager, backed by LoadTsFileMemoryManager and the query operator pool.
• Propagate LoadRuntimeOutOfMemoryException during parser initialization instead of treating it as TsFile corruption and falling back.

Tests

• LoadTsFileParserPipeMemoryIsolationTest: PipeDataNodeResourceManager.memory() throws if accessed; the real Load scan parser still reads the TsFile, records query-pool usage, and releases it.
• LoadTreeStatementDataTypeConvertExecutionVisitorTest#testLoadScanParserUsesQueryMemoryPoolInsteadOfPipeMemory: query-pool usage increases while Pipe usage is unchanged.
• LoadTsFileMemoryManagerTest and TsFileInsertionEventParserTest pass; Spotless/checkstyle pass.
• The latest incremental compile is additionally blocked by pre-existing stale cross-module Subscription/Thrift generated APIs, unrelated to this change.

Scope note

The existing Load conversion semaphore only reads Pipe capacity to size permits; this change removes parser working-memory allocations from the Pipe pool.

---

This PR has:

• been self-reviewed.
• added comments explaining the ownership boundary.
• added or updated unit tests for the new code paths.
• added integration tests (not applicable to this unit-level memory ownership fix).

---

Key changed/added classes

• TsFileInsertionEventParserMemoryBlock / TsFileInsertionEventParserMemoryManager
• LoadTsFileParserMemoryManager
• TsFileInsertionEventParser, scan/query/table parser implementations
• LoadTreeTsFileTabletIterator and LoadTableStatementDataTypeConvertExecutionVisitor
• Load memory/parser isolation tests

[codecov]

Codecov Report

❌ Patch coverage is 84.40367% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.61%. Comparing base (7e2c453) to head (277e61e).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
...mmon/tsfile/parser/TsFileInsertionEventParser.java	57.14%	3 Missing ⚠️
.../parser/query/TsFileInsertionEventQueryParser.java	62.50%	3 Missing ⚠️
.../parser/table/TsFileInsertionEventTableParser.java	72.72%	3 Missing ⚠️
...e/load/converter/LoadTreeTsFileTabletIterator.java	50.00%	3 Missing ⚠️
...ine/load/memory/LoadTsFileParserMemoryManager.java	92.30%	3 Missing ⚠️
...arser/TsFileInsertionEventParserMemoryManager.java	93.33%	1 Missing ⚠️
...TableStatementDataTypeConvertExecutionVisitor.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #18419   +/-   ##
=========================================
  Coverage     43.61%   43.61%           
  Complexity      374      374           
=========================================
  Files          5393     5395    +2     
  Lines        385958   386039   +81     
  Branches      50267    50277   +10     
=========================================
+ Hits         168337   168384   +47     
- Misses       217621   217655   +34     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jt2594838]

If resized twice with size 0, will an NPE be triggered?

[Caideyipi]

Thanks for checking. The first resize to 0 closes the delegate and sets the tracked usage to 0; a second resize to 0 returns before dereferencing the null delegate because the usage is unchanged. I added a regression assertion for the repeated zero-size resize in 277e61e.

[sonarqubecloud]

Quality Gate passed

Issues
29 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.9% Duplication on New Code

See analysis details on SonarQube Cloud