[CORE] Remove the leftover PromotePrecision shim and its decimal rescale path

[jackylee-ch]

Gluten still ships a hand-written org.apache.spark.sql.catalyst.expressions.PromotePrecision in all four shim modules, plus the decimal-arithmetic rewrites built around it. Both are unreachable now that Spark 3.3 support is gone, and one comment in ExpressionConverter still says otherwise.

Why it exists. Up to Spark 3.3, DecimalPrecision wrapped decimal operands in PromotePrecision(Cast(child, <wider type>)) and the operation in CheckOverflow. Velox derives a decimal result type from its input types, so the widened operands gave the wrong scale, and DecimalArithmeticUtil grew three rewrites to undo them: recover a literal's real precision/scale, narrow an integral operand's cast to the minimal decimal type, and strip decimal→decimal widening casts. When 3.4 deleted the expression (SPARK-39316), #3360 added a transparent stub in Spark's package so one code path could still serve 3.3 and 3.4; it was then copied to 3.5 (#4822), 4.0 (#9768) and 4.1.

Why it is no longer needed. Beyond the node simply never appearing, Spark 3.4+ performs all three adjustments itself — BinaryArithmetic.resultDecimalType carries the result type, DecimalPrecision.decimalAndDecimal only rewrites BinaryComparison, and nondecimalAndDecimal casts via DecimalType.forType / fromLiteral. So Gluten's three rewrites return their input unchanged. The same reasoning retires the CheckOverflow(BinaryArithmetic, ...) case: in 3.4–4.1 only the encoder path constructs CheckOverflow, while table inserts and Sum build the InTableInsert / InSum variants.

To remove

• DecimalArithmeticUtil: the three identity rewrites and the private helpers only they reach
• ExpressionConverter: the PromotePrecision case and pass-through alternative, the unreachable CheckOverflow(BinaryArithmetic, ...) case, and this comment
• the promote_precision signature and name constant — no native backend implements it
• the four shim stubs
• SparkShims.widerDecimalType and its overrides, whose only caller goes away above

Two things to watch

1. isDecimalArithmetic admits Remainder/Pmod, but result-type derivation throws for them — today that throw is the only thing keeping decimal % decimal off Velox. Keep an explicit rejection and add a fallback test.
2. This may close [VL] Incorrect result type of nested decimal arithmetic expressions #7082, which blames exactly this machinery and suggests keeping PromotePrecision(Cast(...)). Worth running its repro on 3.5/4.1 first: if it passes, add it as a test and close that issue.

No behaviour change expected otherwise; the result type Gluten declares already matches Spark's. Follow-up to #12807.

[jackylee-ch]

cc @LuciferYang @zhouyuan @jiangjiangtian @rui-mo

[LuciferYang]

Let me look into this.

[rui-mo]

Thanks @jackylee-ch. This makes sense to me.

[LuciferYang]

Looked into it. Everything here holds, and the removal is up as #13002.

What I checked beyond what the issue says. The strongest argument for the three rewrites being identity does not need Spark's behaviour at all: since 3.4 PromotePrecision is Gluten's own class, and nothing in the repository constructs it. The only withNewChildren on it sits inside rescaleCastForOneSide, which is reachable only from a match on PromotePrecision itself, so the rewrites cannot fire on any supported version regardless of what DecimalPrecision does. For the CheckOverflow(BinaryArithmetic, ...) case I checked the construction sites on v3.4.4, v3.5.5, v4.0.2 and v4.1.1: there are three, all in SerializerBuildHelper, where an encoder converts a JVM BigDecimal through a StaticInvoke. Nothing wraps it around an arithmetic node.

On the first thing to watch, the explicit rejection stays. I did try the fallback test you suggested and then dropped it: asserting that the plan holds no ProjectExecTransformer passes whenever the stage falls back for any reason, and velox_backend_ansi.yml runs that suite with ANSI on, where everything falls back, so the test would have gone green while proving nothing. It is a unit test on getResultType instead, which pins the rejection directly and runs on all four versions.

One correction to the issue text, because it affects where the guard actually bites. getResultType has a single caller, and it sits in the branch taken when transformCheckOverflow is set. Velox and bolt set it; clickhouse overrides it to false and takes the generic arm in the same case, which offloads decimal % decimal as a plain modulus. So the throw is what keeps % and pmod off the native path on velox and bolt, not everywhere.

Both removed ExpressionConverter arms are behind !transformCheckOverflow, so that half of the diff is clickhouse-only and I could not exercise it. There is no clickhouse native library on this machine, and -Pbackends-clickhouse only compiles on 3.5 at all, since CHRuleApi and src-delta/main reference Delta 3.3 APIs that only the spark-3.5 profile selects. A Run Gluten Clickhouse CI pass on #13002 would be worth having before it merges.

cc @rui-mo @jiangjiangtian