[BugFix] Fix incorrect execution plan when generated column rewrite in join relation if left table and right table has the same column name (backport #52584)

[mergify]

Why I'm doing:

This problem is introduced by pr #50398. In this pr, we introduce some new rule for generated column rewriting. The basic idea is following:

1. Collect the rewriting relation in every SELECT scope in query. (Expr -> SlotRef)
2. Translate the expression relation into Operator mapping: ScalarOperator -> ColumnRefOperator
3. Introduce new rule says ReplaceScalarOperatorRule, use this new rule to replace the ScalarOperator by ColumnRefOperator when generating the logical plan in optimizer.

This problem is that, ReplaceScalarOperatorRule use ScalarOperator.isEquivalent to check if a ScalarOperator hit the rule instead of using ScalarOperator.equals. ScalarOperator.isEquivalent does not check the operator id but this id will be used to identify the column with the same column name but come from different table in JOIN relation. (e.g column xx in TABLE A and column xx in TABLE B has same name but different id, in this case, ScalarOperator.isEquivalent return true but ScalarOperator.equals return false). So in this case, we will get the wrong mapping and generated a incorrect plan for generated column rewrite.

What I'm doing:

1. Using ScalarOperator.equals instead
2. Introduce session variables disable_generated_column_rewrite for disable the generated column rewrite if we want.

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 3.3
  • 3.2
  • 3.1
  • 3.0
  • 2.5

---

This is an automatic backport of pull request #52584 done by [Mergify](https://mergify.com). ## Why I'm doing: This problem is introduced by pr #50398. In this pr, we introduce some new rule for generated column rewriting. The basic idea is following: 1. Collect the rewriting relation in every `SELECT` scope in query. (`Expr` -> `SlotRef`) 2. Translate the expression relation into Operator mapping: `ScalarOperator` -> `ColumnRefOperator` 3. Introduce new rule says `ReplaceScalarOperatorRule`, use this new rule to replace the `ScalarOperator` by `ColumnRefOperator` when generating the logical plan in optimizer.

This problem is that, ReplaceScalarOperatorRule use ScalarOperator.isEquivalent to check if a ScalarOperator hit the rule instead of using ScalarOperator.equals. ScalarOperator.isEquivalent does not check the operator id but this id will be used to identify the column with the same column name but come from different table in JOIN relation. (e.g column xx in TABLE A and column xx in TABLE B has same name but different id, in this case, ScalarOperator.isEquivalent return true but ScalarOperator.equals return false). So in this case, we will get the wrong mapping and generated a incorrect plan for generated column rewrite.

What I'm doing:

1. Using ScalarOperator.equals instead
2. Introduce session variables disable_generated_column_rewrite for disable the generated column rewrite if we want.

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
• This is a backport pr

[mergify]

Cherry-pick of af20339 has failed:

On branch mergify/bp/branch-3.3/pr-52584
Your branch is up to date with 'origin/branch-3.3'.

You are currently cherry-picking commit af20339fc0.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   fe/fe-core/src/main/java/com/starrocks/sql/analyzer/QueryAnalyzer.java
	modified:   fe/fe-core/src/main/java/com/starrocks/sql/optimizer/rewrite/scalar/ReplaceScalarOperatorRule.java
	modified:   fe/fe-core/src/test/java/com/starrocks/sql/plan/GeneratedColumnTest.java
	modified:   test/lib/sr_sql_lib.py
	modified:   test/sql/test_materialized_column/R/test_generated_column_rewrite
	modified:   test/sql/test_materialized_column/T/test_generated_column_rewrite

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   fe/fe-core/src/main/java/com/starrocks/qe/SessionVariable.java

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[mergify]

@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr