[fix](mtmv) Infer null-reject from INNER JoinEdge for multi-hop outer join MV rewrite

[seawinde]

What problem does this PR solve?

Issue Number: N/A

Related PR: #30374

Problem Summary:

In multi-hop LEFT JOIN materialized view transparent rewrite (e.g., fact LEFT JOIN dim1 LEFT JOIN dim2), when the query has a WHERE clause that null-rejects only the outermost dimension table (e.g., WHERE dim2.col = 'value'), the MV rewrite fails with "Predicate compensate fail".

Root cause: In AbstractMaterializedViewRule.containsNullRejectSlot(), the original code only checked filter predicates (queryPredicates) for NOT NULL evidence. After the Nereids rewrite pipeline runs:

1. EliminateOuterJoin converts all eligible LEFT JOINs → INNER (cascading through InferJoinNotNull across multiple passes)
2. EliminateNotNull unconditionally removes all generated NOT NULL predicates (isGeneratedIsNotNull=true)

By the time MV rewrite (exploration phase) runs, the query plan has INNER JOINs but zero NOT NULL filter predicates. The only surviving predicate is the user's WHERE clause (e.g., dim2.region_name = 'West'), which can only prove NOT NULL for outermost dim2 slots — leaving intermediate dim1 slots uncovered.

Fix: Read INNER JoinEdge conditions directly from the query HyperGraph. After EliminateOuterJoin converts LEFT→INNER, JoinEdge objects retain their INNER type and join condition expressions even though EliminateNotNull removes filter-level NOT NULL predicates. ExpressionUtils.inferNotNullSlots() extracts NOT NULL slots from these INNER join conditions, covering all intermediate join tables.

File	Change Description
AbstractMaterializedViewRule.java	containsNullRejectSlot(): Add loop over INNER JoinEdges to collect NOT NULL slots from join conditions via inferNotNullSlots. Also add shuttleExpressionWithLineage for correct slot-level mapping.
NullRejectInferenceTest.java (new)	FE unit test: query=2-hop INNER JOIN vs view=2-hop LEFT JOIN, verifies predicatesCompensate succeeds
outer_join_two_hop_null_reject.groovy (new)	Regression test: 3 tables, async MV with 2-hop LEFT JOIN + WHERE + aggregate rollup, verifies rewrite success and result correctness

2-hop example walkthrough:

Query HyperGraph (after EliminateOuterJoin):
  JoinEdge 1 (INNER): o.store_id = d.id    → {o.store_id, d.id} NOT NULL
  JoinEdge 2 (INNER): d.id = r.store_id    → {d.id, r.store_id} NOT NULL
  FilterEdge:         r.region_name = 'West' → {r.region_name} NOT NULL

queryNullRejectSlots = {o.store_id, d.id, r.store_id, r.region_name}

requireNoNullableViewSlot (view has LEFT JOINs):
  Set 1: {d.id, d.store_name} ∩ queryNullRejectSlots → {d.id} ≠ ∅ ✓
  Set 2: {r.store_id, r.region_name} ∩ queryNullRejectSlots → {r.store_id, r.region_name} ≠ ∅ ✓

Release note

Fix multi-hop LEFT JOIN materialized view transparent rewrite failure when the WHERE clause only references the outermost dimension table.

Check List (For Author)

• Test

  • Regression test
  • Unit Test

• Behavior changed:

  • No.

• Does this need documentation?

  • No.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[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?

[seawinde]

run buildall

[seawinde]

run buildall

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 100.00% (20/20) 🎉
Increment coverage report
Complete coverage report

[seawinde]

run buildall

[hello-stephen]

FE Regression Coverage Report

Increment line coverage 100.00% (20/20) 🎉
Increment coverage report
Complete coverage report

[morrySnow]

/review

[github-actions]

Findings:

1. Blocking: containsNullRejectSlot() now harvests null-reject evidence from JoinEdge, but only for INNER_JOIN. This rule already supports ASOF_LEFT/RIGHT_{INNER,OUTER}_JOIN, EliminateOuterJoin can convert ASOF outer joins to ASOF inner joins, and HyperGraphComparator already models that inference. As written, the same root cause remains for the parallel ASOF rewrite path.
2. Test gap: the new end-to-end regression uses mv_rewrite_success_without_check_chosen(...), so it can pass even when the memo plan says .mv_name not chose and both executions read the base tables. That means the only new regression case does not prove the fixed rewrite is actually selected.

Checkpoint conclusions:

• Goal of the task: Fix multi-hop outer-join MV rewrite null-reject inference after join elimination. The ordinary INNER path is addressed, but the supported ASOF path is still missing, so the goal is only partially met.
• Scope/focus: The code change is small and focused on MV null-reject inference plus tests.
• Concurrency/locking: No new concurrency, locking, or lifecycle risks were introduced here.
• Config/compatibility/persistence/data writes: None involved.
• Parallel code paths: Not fully covered; ASOF join inference is the missing sibling path.
• Special conditions: The new join-type check is too narrow (isInnerJoin() only).
• Test coverage: There is positive coverage for the ordinary INNER case, but no ASOF coverage, and the new regression does not assert that the MV is actually chosen.
• Observability/performance: No obvious new observability or performance concerns in this path.

I did not run FE unit/regression suites in this review environment.

[github-actions]

PR approved by at least one committer and no changes requested.

not problem

[github-actions]

PR approved by anyone and no changes requested.