Refactor BitwiseXOR operator using ScalarUDF framework

[Acfboy]

Which issue does this PR close?

• Part of Unifying Operator Handling with the Scalar Function Framework #20018

Rationale for this change

This PR is a pilot implementation of #20018. By refactoring operator into the ScalarUDF framework, we aim to:

1. Move operator type handling from the physical execution phase to the logical plan phase, consistent with scalar functions.
2. Simplify the operator handling logic which is currently scattered across the codebase.

What changes are included in this PR?

Refactor BitwiseXOR operator handling using ScalarUDF framework

Are these changes tested?

Yes.

• All existing integration tests pass.
• Move some existing binary operator tests to the new UDF-based implementation.

Are there any user-facing changes?

No.

[Acfboy]

Hi @2010YOUY01, I've submitted the pilot pr for bitwise_xor as we discussed. Looking forward to your feedback!

The implementation logic for bitwise_or and bitwise_and is very similar to bitwise_xor. If this approach is acceptable, I plan to refactor those operators using macros in a follow-up step.

[Jefffrey]

At what phase of planning do we do this replacement? I have a concern that we have optimizer rules based around binary exprs that are BitwiseXor ops that might be made invalid if we substitute it with a scalar UDF 🤔

[Acfboy]

Hi @Jefffrey, thanks for the feedback!

My apologies, I didn't consider this thoroughly enough. I realize now that making this change directly (during the initial conversion from statement to LogicalPlan) would break the optimizer. For instance, I haven't even migrated the logic from simplify_expr to the UDF's simplify method yet.

I will convert this pr to a draft for now and carefully study the impact of this change on existing optimization rules.