fix: incorrect nullability of InList expr

[jonahgao]

Which issue does this PR close?

None

Rationale for this change

Similar to #6786 .

We can safely assume that the InList expr is non-nullalbe only if all of its subexpressions are non-nullable.

An example of a nullable expression is:

DataFusion CLI v27.0.0

❯ select 1 in(2, null);
+----------------------------------------------------------------------+
| Int64(1) IN (Map { iter: Iter([Literal(Int64(2)), Literal(NULL)]) }) |
+----------------------------------------------------------------------+
|                                                                      |
+----------------------------------------------------------------------+

What changes are included in this PR?

• fix incorrect nullability of InList expr
• cleaner code for insert.rs

Are these changes tested?

Yes

Are there any user-facing changes?

No

[alamb]

This is really nicely written and tested @jonahgao 👏 Thank you very much

[jackwener]

I want to know why use this number? Is it the practice from other systems?

[jackwener]

spark handle it simplified.

override def nullable: Boolean = children. Exists(_.nullable)

[jonahgao]

I want to know why use this number? Is it the practice from other systems?

@jackwener No. The nullable function may be called multiple times during the optimization phase,
So I think adding a limitation would be preferable in order to prevent it from being excessively slow.
But I'm not quite sure what would be an appropriate number.

spark handle it simplified.

override def nullable: Boolean = children. Exists(_.nullable)

This seems to be a cache style.
We can implement this by precomputing nullable in the InList::new() function.
But the disadvantages are：

• We need a new field for the InList struct
• The precomputed nullable may not be used.
• Calculating nullable requires input_schema

@jackwener Which solution do you prefer?

Update: It seems challenging to accomplish. I need to take a closer look.

[alamb]

As @jonahgao hints at , trying to add some sort of cache / memoization is going to be challenging given Rust and how DataFusion is structured

I think the current PR solution is good:

1. It is well tested
2. It is conservative (it might say an InList is nullable that isn't, but I think that will not generate wrong results, only potentially less optimal plans)

Thus I think we should merge this PR as is and then as a follow on PR we can remove the limit or increase it, etc.

[jackwener]

thanks @jonahgao @alamb