Constant-folding causes unmatched behavior of IN predicate in expression fuzzer

[kagamiori]

Expression fuzzer came across a failure where only simplified path threw an exception in IN predicate: #3041. The reason is that IN predicate only support constant IN list. While the IN list in the original fuzzer-generated expression is a reverse subexpression, this subexpression is constant-folded when evaluating the common path, so IN predicate does receive a constant IN list. On the other hand, the simplified path does not perform constant-folding, so IN predicate throws because of non-constant IN list.

Looking at each evaluation path individually, however, I found their behaviors both makes sense, so this error should be addressed in the fuzzer instead of the evaluators themselves. Below is a possible solution to avoid running into the same issue in the future:

1. The behavior of common path does not change.
2. For the simplified path, first execute it without constant-folding.
   2.a. If only simplified path throws, let simplified path retry with constant-folding.

The rationale behind this idea is the following:
(1) Performing constant-folding in the simplified path means we could not detect bugs in the constant-folding logic, so we'd like to enable it in the simplified path only when constant-folding causes unmatched behavior.
(2) "only simplified path threw" often means unmatched behavior between the two paths caused by optimizations performed in the common path.
(3) After simplified path retry, if it was constant-folding that caused the mismatch, the new behaviors should match now. If it was a bug somewhere else (except in the constant-folding logic itself), the mismatch should retain.

[kagamiori]

cc: @mbasmanova

[mbasmanova]

CC: @oerling

[kgpai]

Why is inpredicate written to only require that the predicate vector be constant. I see the constant case as an optimization (and the default in large number of cases), but there shouldnt be a fundamental reason to not support non constant vectors too right ?