Fix eq_any's nullability

[Ten0]

PG returns null for IN expressions if LHS is null or if result depends on a NULL inner element of the array.
The return value of the IN & co expressions was incorrectly represented as non-nullable in this case.

While this is a breaking change, it should probably also be considered a bugfix, so we should be able to release it.

[kw217]

Code looks good, and the test is very clear - thank you. I agree this is technically a bugfix, but I fear it has the potential to cause quite a bit of breakage so I'm nervous about releasing it. Do we have any way of checking impact (e.g., anything like crater?). Anyone who has a nullable column that actually never has null in it, and uses eq_any, will have been getting away with this and will be surprised by the change.

[Ten0]

I imagine most uses of eq_any are actually to filter, and because filter accepts both they will keep compiling.
We have 500 uses of eq_any in our codebase and all of those are .filter.

[kw217]

Fair enough. In the first 30 or so repo hits in a quick GitHub search all but one instance was inside a filter; the exception was inside an order: https://github.com/johnmai-dev/newbee-mall-api-rs/blob/f46091f75fb5be7962e4c9676bb6d9e871534535/src/models/goods.rs#L180 . That too will accept either, so I agree there probably shoudn't be breakage.

[weiznich]

I personally would expect that this won't cause much breakage for using a.eq_any(b) outside of filter. I see more potential for breakage by having some functions that return Box<dyn BoxableExpression<SqlType = Bool>> which contains such an IN expression and suddenly turn to Nullable<Bool> due to this change.

That written: I still would see that as bugfix and therefore allowed breakage, but we should have an explicit changelog entry for this, so that it does not get lost before the next update.