Handle NaN when extracting predicate

[findepi]

Fixes #4119
Fixes #4272

[martint]

We should probably stop using == checks against types to avoid any future backward compatibility issues if we decide to create instances on the fly, and for consistency across all type checks. .equals() is more robust and can be implemented internally to do the == check as necessary.

[findepi]

this is omnipresent pattern across a codebase, so we would need to (a) update all the paces and (b) have some safeguards on CI.
especially until we do (a), there isn't much of an added value in avoiding them in new code.

[losipiuk]

different commit?

[findepi]

I will rename Handle NaN when extracting predicate to better describe its holistic approach

[findepi]

@sopel39 suggests we can skip the NaN values instead (like we skip NULLs).

[findepi]

i pushed an update

[findepi]

@sopel39 @losipiuk @martint
i added a bit of new code.
Not a ton, but would appreciate second look.
I will squash to order the commits appropriately.

[sopel39]

Generally, accepting all non-null values because we've seen NaN is really aggressive. I guess it shouldn't occur in practice too much

[sopel39]

Do we need to handle empty as special case? Should Domain.multipleValues handle that
in order to reduce iffs?
For example:

Domain.create(ValueSet.copyOf(type, ImmutableList.of()), false).isNone() == true

Yet multipleValues is implemented as

    public static Domain multipleValues(Type type, List<?> values)
    {
        if (values.isEmpty()) {
            throw new IllegalArgumentException("values cannot be empty");
        }
        if (values.size() == 1) {
            return singleValue(type, values.get(0));
        }
        return new Domain(ValueSet.of(type, values.get(0), values.subList(1, values.size()).toArray()), false);
    }

[findepi]

i do not have a strong opinion. There are exactly 3 non-test call sites for multipleValues, so updating it in a follow up would not be a problem.

[sopel39]

Consider adding comment. It might not be obvious for reader why NaN makes TupleDomain accept all non-null values.

[findepi]

This knowledge is sprinkled in multiple places in the code base already.
There seems to be no good place to place such a comment though.