SQL: Fix bug with optimization of null related conditionals

[matriv]

The SimplifyConditional rule is removing NULL literals from those
functions to simplify their evaluation. This happens in the Optimizer
and a new instance of the conditional function is generated. Previously,
the dataType was not set properly (defaulted to DataType.NULL) for
those new instances and since the resolveType() wasn't called again
it resulted in returning always null.

E.g.:

SELECT COALESCE(null, 'foo', null, 'bar')

COALESCE(null, 'foo', null, 'bar')
-----------------
null

This issue was not visible before because the tests always used an alias
for the conditional function which caused the resolveType() to be
called which sets the dataType properly.

E.g.:

SELECT COALESCE(null, 'foo', null, 'bar') as c

c
-----------------
foo

[elasticmachine]

Pinging @elastic/es-search

[costin]

I think the issue here is that the dataType detection is incorrect - namely instead of using commonType, the first not-null type should be used (otherwise it default to null).
Simple and effective and works regardless of optimizations

[matriv]

The commonType is there for flexibility. Let's say we have an "test" index with:

"n1" : {"type": "integer"},
"n2": {"type":"long"}

and we have a document:

{"n2": 10}

(n1 is null)

and we have a query:

SELECT COALESCE(n1, n2) FROM test

if the data type is set to the 1st non-null it will be set to "integer" instead of "long'.

[costin]

Okay, then keep looping to find the common dataType that is not null.
Once computed the DataType should remain the same for the given expression - I don't see a reason for changing it or recalculating it (not that we would want to considering it does has side-effects in this case).

[costin]

LGTM

[astefan]

LGTM