equivalence classes: use normalized mapping for projection

[askalt]

Which issue does this PR close?

Closes #14326.

Rationale for this change

See the issue above.

What changes are included in this PR?

Now projection mapping source expression is normalized before we lookup in the map.

Are these changes tested?

Yes, there is a unit test.

Are there any user-facing changes?

No

[berkaysynnada]

Thank you @askalt. I'll review this in detail.

One initial suggestion: instead of adding a unit test and introducing additional testing components, I believe the same logic can be reproduced in an .slt test. You can assert the intended plan more effectively.

[askalt]

Thank you @askalt. I'll review this in detail.

One initial suggestion: instead of adding a unit test and introducing additional testing components, I believe the same logic can be reproduced in an .slt test. You can assert the intended plan more effectively.

Thank you!
I checked .slt tests, but I don't sure that for now we can assert plan properties like equivalence classes. If I overlooked it, please correct me.

[ozankabak]

I am guessing what is meant was writing an SLT test whose output plan would change if this logic/fix weren't there. Maybe an optimization that wouldn't take place because of the normalization is not done properly.

[askalt]

I added a test to .slt. It was slightly tricky because setting up a table with existing equivalence classes (e.g., a being an alias for b) is not very straightforward. I took advantage of the fact that the projection [x, y] with the filter x == y generates a new equivalence class.

Additionally, I left a small unit test in class.rs. It doesn’t introduce new logic with some Execs, but it might be useful for understanding what's happening during debugging.