Pipe: Load TsFile classes from parent class loader

[Caideyipi]

Description

Problem

PipePluginClassLoader uses child-first loading for external plugin dependencies, while delegating shared API packages to the parent class loader. TsFile classes are also exposed by the Pipe API boundary, for example TabletInsertionEvent#processTablet passes an org.apache.tsfile.write.record.Tablet to plugin code.

If an external plugin bundles TsFile, the plugin class loader currently loads a second copy of Tablet. A core-created Tablet can then fail with a same-class-name ClassCastException because the two copies have different class loaders, preventing the sink from processing events.

Fix

Add org.apache.tsfile. to the parent-first package prefixes. This keeps TsFile types shared across the Pipe API boundary while preserving child-first loading for ordinary plugin implementation classes and dependencies.

Test

Add a regression test that creates a plugin JAR containing a duplicate fake org.apache.tsfile.write.record.Tablet, then verifies that the plugin class loader resolves the parent TsFile class. The existing test continues to verify child-first loading for normal plugin classes.

Tested with:

./mvnw -pl iotdb-core/node-commons -Dtest=PipePluginClassLoaderTest -DskipITs test

This PR has:

• been self-reviewed.
• added unit tests covering the new class-loading path.

Key changed/added classes

• PipePluginClassLoader
• PipePluginClassLoaderTest