Simplify expr = L1 AND expr != L2 to expr = L1 when L1 != L2

[simonvandel]

Which issue does this PR close?

• Closes #.

Rationale for this change

Add a simplifier rule to remove a comparison.
It's probably unlikely that a human would write such an expression, but a generated query, or other optimizations, may lead to such an expression.

What changes are included in this PR?

Simplify expr = L1 AND expr != L2 to expr = L1 when L1 != L2

Are these changes tested?

Added unit tests and SLT.
The first commit shows the plan before the optimization.

Are there any user-facing changes?

Fewer runtime-ops if the plan contains the pattern.

[xudong963]

A clever simplify! It could reduce the CPU cost for FilterExec and row filter in parquet

[alamb]

is this right? It looks like it has rewritten

((dept_name != 'Engineering' AND e.name = 'Alice') OR (name != 'Alice' AND e.name = 'Carol'));

to

((dept_name != 'Engineering' AND e.name = 'Alice') OR (e.name = 'Carol'));

But name and e.name are different 🤔

[alamb]

Update -- looking at this, it seems like actually the predicate actually did resolve both name references to the same thing (name@1) in the physical plan

01)FilterExec: dept_name@2 != Engineering AND name@1 = Alice OR name@1 != Alice AND name@1 = Carol

Maybe we can update this test (in a follow on PR) so it uses the fully qualified column references to make it clearer the intent

((d.dept_name != 'Engineering' AND e.name = 'Alice') OR (e.name != 'Alice' AND e.name = 'Carol'));

[alamb]

Thanks @simonvandel and @xudong963

[alamb]

Update -- looking at this, it seems like actually the predicate actually did resolve both name references to the same thing (name@1) in the physical plan

01)FilterExec: dept_name@2 != Engineering AND name@1 = Alice OR name@1 != Alice AND name@1 = Carol

Maybe we can update this test (in a follow on PR) so it uses the fully qualified column references to make it clearer the intent

((d.dept_name != 'Engineering' AND e.name = 'Alice') OR (e.name != 'Alice' AND e.name = 'Carol'));