[IOTDB-17610] Fix LIKE predicate with dynamic pattern expressions

[DaZuiZui]

Description

Fixes #17610.

Content1: Support dynamic pattern expressions in LIKE predicates

This PR allows table-model LIKE predicates to accept pattern expressions that are evaluated at runtime, such as:

alarmname LIKE concat('OK', '%')
alarmname LIKE 'OK' || '%'
alarmname LIKE concat('正', '常', '%')

Before this change, the analyzer/planner path did not correctly handle non-literal pattern expressions on the right side of LIKE. This PR keeps dynamic LIKE patterns in the normal expression planning/evaluation path, so they are evaluated consistently with other scalar expressions.

Design choice: dynamic patterns are handled in the relational analyzer/planner flow instead of adding special execution-only logic.

Alternative considered: fold or rewrite all LIKE patterns during analysis. That is only safe for constant patterns, so dynamic expressions should stay in the regular expression path.

Content2: Keep metadata predicate pushdown conservative

Metadata predicate conversion remains limited to predicates that can be safely represented as schema filters. Dynamic LIKE patterns are not pushed into metadata filters because their final values are unknown during metadata predicate conversion.

Design choice: only literal-safe LIKE predicates are converted for metadata pushdown; dynamic LIKE expressions remain normal filters.

Alternative considered: evaluate simple functions such as concat(...) during metadata conversion. That would introduce partial function evaluation into schema predicate conversion and could become inconsistent with the normal evaluator.

Content3: Stabilize related load-tsfile scheduling path

This PR also adjusts the related load-tsfile planning/scheduling path needed by the affected dual-tree auto basic CI scenario. The change keeps the existing load node and scheduler organization, preserving the required load-node information across planning and scheduling.

Design choice: extend the existing load-tsfile node/scheduler flow instead of introducing a new wrapper node.

Alternative considered: add a new scheduling wrapper node. That would add extra visitor and node handling for a narrow case, while the existing load node flow is sufficient.

---

This PR has:

• been self-reviewed.
• 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

• PredicatePushIntoMetadataChecker: keeps metadata pushdown checks safe for non-literal LIKE patterns.
• ConvertSchemaPredicateToFilterVisitor: avoids converting unsupported dynamic LIKE patterns into schema filters.
• RelationPlanner: preserves dynamic LIKE expressions in the relational planning path.
• AnalyzerTest: adds coverage for LIKE concat(...), LIKE ... || ..., and Chinese string patterns.
• LoadTsFileNode, LoadSingleTsFileNode, LoadTsFileScheduler, LogicalPlanVisitor: adjust load-tsfile planning/scheduling behavior for the related CI path.
• LoadTsFileNodeTest: updates load-node test coverage.
• IoTDBPipeReceiverAutoCreateDisabledIT: covers the related dual-tree auto basic integration path.

Tests

./mvnw spotless:apply -pl iotdb-core/datanode,integration-test -P with-integration-tests -ntp
git diff --check
./mvnw test -pl iotdb-core/datanode -am -Dtest=AnalyzerTest#expressionTest -DfailIfNoTests=false -Dsurefire.failIfNoSpecifiedTests=false -ntp
./mvnw verify -DskipUTs -Dit.test=IoTDBPipeReceiverAutoCreateDisabledIT -DfailIfNoTests=false -Dfailsafe.failIfNoSpecifiedTests=false -pl integration-test -am -P with-integration-tests -P MultiClusterIT2DualTreeAutoBasic -ntp
./mvnw package -P with-integration-tests -DskipTests -ntp

Manual verification on a packaged standalone IoTDB cluster:

SELECT time, deviceid, alarmname
FROM quota_info
WHERE alarmname LIKE concat('OK','%')
ORDER BY time;

SELECT time, deviceid, alarmname
FROM quota_info
WHERE alarmname LIKE 'OK' || '%'
ORDER BY time;

SELECT time, deviceid, quotaid, alarmname
FROM quota_info
WHERE alarmname LIKE concat('正','常','%')
ORDER BY time;

All three queries returned the expected rows.