GH-3632: Fix record-level notIn evaluation

[wgtmac]

Rationale for this change

The generated record-level filter for notIn can accept a row after checking only the first non-matching value in the literal set. For example, notIn(col, {1.0, 3.0}) should reject 3.0, but the current logic can accept it after seeing 3.0 != 1.0.

What changes are included in this PR?

• Evaluate notIn by checking whether any literal equals the row value before deciding the result.
• Add a regression test for multi-value notIn record-level filtering.

Are these changes tested?

• ./mvnw -q -Drat.skip=true -DskipTests -pl parquet-generator,parquet-column install
• ./mvnw -q -Drat.skip=true -pl parquet-hadoop -Dtest=TestRecordLevelFilters -Dsurefire.failIfNoSpecifiedTests=false test

Are there any user-facing changes?

This fixes record-level filtering for notIn predicates with multiple literal values.

Closes #3632

[wgtmac]

Just caught this bug while working on #3393. Could you please take a look at this? @gszadovszky @Fokko

[gszadovszky]

This branch still looks incorrect for notIn sets that contain null plus non-null values. For example, notIn(col, {null, 3.0}) will emit setResult(true) for any non-null value, so a row where col == 3.0 is still kept.

[wgtmac]

Fixed in the latest push. The generated evaluator now handles null membership only in updateNull(), and update(value) still scans the non-null values with the column comparator. Added a regression test for in/notIn with {null, 3.0}; notIn now rejects col == 3.0 and keeps only the non-matching non-null value.

[gszadovszky]

Thanks @wgtmac for fixing this!
LGTM.

[wgtmac]

Thank you, @gszadovszky!