This is an automated cherry-pick of #46450

What problem does this PR solve?

Issue Number: close #42788

Problem Summary:

What is changed and how it works?

currently Expression.Hashcode() functionality is only used in some limited comparison cases, so lazy computation is necessary.
Say memory formular for every DNF item is m(?)

OR                 root node                 hashcode mem consumption: 
(a  OR)                                       m(a) + m(child) = m(a) + m(b) + m(c) + ... m(y) + m(z)
  (b  OR)
     (c  OR)
        (d  OR)
           (e  OR)
              (f  OR)                         m(f) + m(child) = m(f) + m(x) + m(y) + m(y)  
                 (x  OR)                      m(x) + m(child) = m(x) + m(y) + m(y)  
                   (y   z)                    m(y);  m(z);      
                                              total: m(a)+m(b)*2+m(c)*3+ ....+m(x)*(n-1)+m(y)*n+m(z)*n, assume the tree depth is n.

from the case above, when computing the hashcode from the raw tree format, additional mem consumption should be allocated since the hashcode cache in every OR Expression except for basic column hashcode comsumption: (m(a) + m(b) + m(c) + ... m(y) + m(z))

additionally, actually we rarely need to compute the hashcode from root node, from the most usage from TiDB expression deduplication cases after flatten DNF expressions, what we only need to do is to output every hashcode for every single flattenDNFItem above, which consuming as just few as (m(a) + m(b) + m(c) + ... m(y) + m(z)) as we said above.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

planner: don't recompute the hashcode when generated column substitution 't happened