[fix](join) Eliminate joins with never-true conditions

[mrhhsg]

What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary:

A one-sided outer join whose condition folds to FALSE or NULL still remained in the logical plan. Although the nullable side can only produce NULL-padded columns, the optimizer did not expose those columns as uniform NULL values. Consequently, a later null-rejecting inner-join predicate could fail to fold to an empty relation and execute very large nested-loop intermediates for a query whose result is already known to be empty.

This change:

• replaces constant-false/NULL inner and cross joins with an empty relation;
• replaces constant-false/NULL left and right outer joins with a projection over the preserved child plus typed NULL aliases, while preserving output expression IDs, names, qualifiers, types, and order;
• reapplies join-condition elimination immediately after constant propagation rewrites join predicates.

Mark joins, semi/anti joins, full outer joins, and ASOF joins retain their existing behavior.

Release note

Improve query performance by eliminating joins whose conditions are constant FALSE or NULL.

Check List (For Author)

• Test:
  • Unit Test: ./run-fe-ut.sh --run org.apache.doris.nereids.rules.rewrite.EliminateJoinConditionTest (5 tests passed)
  • Regression test: Not run; the focused optimizer unit test covers inner, left outer, right outer, NULL, FALSE, output preservation, and cross-rule constant propagation.
• Behavior changed: Yes (semantically redundant joins are removed; query results are unchanged)
• Does this need documentation: No

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[mrhhsg]

/review

[github-actions]

Opinion: approve. I found no blocking or actionable inline issue in the reviewed diff.

Critical checkpoint conclusions

• Goal and correctness: The change accomplishes the stated goal. A never-true inner/cross join becomes an empty relation; a one-sided outer join becomes the preserved child plus typed NULL aliases; and constant propagation can reapply that elimination so a lower null-padded result can simplify an upper join. The replacement preserves row multiplicity, output order, ExprIds, names, qualifiers, data types, and nullable output semantics.
• Scope and clarity: The change is focused on one rewrite helper, its use from constant propagation, and targeted FE unit tests. It reuses the existing join-condition rule instead of duplicating the transformation.
• Concurrency: This is a statement-local logical-plan rewrite. It adds no shared mutable state, threads, locks, or concurrent lifecycle.
• Lifecycle/static initialization: No new global/static state, ownership protocol, or non-obvious lifecycle is introduced.
• Configuration: No configuration item is added or changed.
• Compatibility: No public API, function symbol, serialized format, persisted metadata, RPC, or FE-BE protocol changes are involved, so rolling-upgrade compatibility is unaffected.
• Parallel paths: The join-type matrix was checked. Mark, full outer, null-aware anti, ordinary semi/anti, and ASOF joins retain their distinct behavior as intended. In the production pipeline, later filter pushdown and empty-relation cleanup remove decisive semi-join work and prevent the alleged cross-product cost for ordinary anti joins.
• Conditional handling: Removing literal TRUE conjuncts remains safe. Literal FALSE/NULL elimination is fenced to non-mark joins and only the join types whose SQL three-valued semantics make the result exact; the excluded join types need different semantics.
• Test coverage: The FE tests cover existing TRUE removal, FALSE inner elimination, NULL/FALSE left and right outer elimination, output reconstruction, and nested null propagation into an upper inner join. This is appropriate focused coverage for the localized planner rewrite; no end-to-end regression case is added.
• Test results: The review runner did not run builds or tests, as required by its review-only instructions. The PR reports the five focused unit tests passing. Current CI shows CheckStyle and the other completed checks passing; the automated code-review check is this pending run.
• Observability: No new user-visible failure mode or distributed runtime path is introduced; additional logs or metrics are not warranted for this deterministic planner rewrite.
• Persistence and transactions: No EditLog, replay, transaction, failover, or persistent-state path is touched.
• Data writes and FE-BE propagation: The change does not write data and adds no variable or plan protocol field that must be propagated to BE.
• Performance: The rewrite removes unnecessary join execution. Projection construction is linear in output width, and the complete downstream rewrite pipeline revealed no material regression or missed hot-path work.
• Other concerns: Error handling, memory safety, volatile-expression evaluation, logical-property invalidation, rewrite ordering, and termination were checked; no additional issue was found.

User focus

No additional user-provided focus points were supplied. The full three-file change and its relevant upstream/downstream planner paths were reviewed.