feat(load): reject managed TsFile directories

[luoluoyuyu]

Description

as the title said

---

This PR has:

• been self-reviewed.
  • concurrent read
  • concurrent write
  • concurrent read and write
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods.
• added or updated version, license, or notice information
• added comments explaining the "why" and the intent of the code wherever would not be obvious
  for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold
  for code coverage.
• added integration tests.
• been tested in a test IoTDB cluster.

---

Key changed/added classes (or packages if there are too many classes) in this PR

[Caideyipi]

[P2] Hoist managed-directory canonicalization out of the recursive traversal

findAllTsFile calls this method for every file and directory it encounters, and every call re-canonicalizes both sequence and unsequence under every local data directory. Directory loading therefore performs 1 + 2 * dataDirCount canonical-path resolutions per entry, even though the managed roots are invariant during one traversal.

On Windows/JDK 17, traversing 5,000 TsFiles with this PR took about 3.24 s with 1 local data directory, 9.68 s with 4, and 37.31 s with 16, before LOAD analysis or execution began. This makes large directory LOADs increasingly expensive for the supported multi-directory configuration.

Please compute the canonical managed roots once at the start of processTsFile and pass that snapshot through the recursion, or cache them alongside the data-directory configuration.

[jt2594838]

Mind this

[luoluoyuyu]

Thanks for the reminder. processTsFileForPipe intentionally bypasses the managed-directory check because Pipe receiver/hardlink sources can be placed under IoTDB-managed paths. We have restricted this branch to createForPipe() call sites guarded by an existing isGeneratedByPipe context; normal table-model LOAD still uses processTsFile(...) and keeps the managed-directory validation.