Filter push down is incorrect for fallible operations

[gatesn]

Issue Description

Both in the current world, and in the upcoming logical plan world, we tend to assume that filters can be arbitrarily re-ordered.

But there is an annoying case, SELECT cast(a, u8) WHERE a < 256)

We must construct the projection as cast(filter(a), u8), otherwise a failure to cast would fail the entire query. The logic on develop switches the order of these operations based on the selectivity of the filter mask.

Solutions:

• We must always apply the filter mask before the projection expression in the FlatLayoutReader.
• Filter push down / pull up rules must take into account whether the operation can error.

Expected Behavior

We must apply the filter mask before the projection expression in the FlatLayoutReader

Actual Behavior

The order of operations is dependent on the density of the mask

I acknowledge that:

• I have searched the Vortex repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[connortsui20]

That's definitely a problem in the old world...

But in the new world we should be able to get around this in the first optimization pass? Or at least in the set of "transformations that are always good to apply" rules.

Note that I think the correct way to do this would be to match on the entire expression (including the < 256 node) which would force us to apply the transform.