common/countdown,params: deduplicate exp-timeout parameter validation #2874

Summary

The exponential-timeout parameter validation lives twice:

• checkExpParams in common/countdown/exp_duration.go (extracted from sanityCheck by fix(common/countdown): fix data race between SetParams and GetTimeoutDuration #2831)
• validateV2ExpTimeoutConfig in params/config_backfill.go

Both enforce the same two rules on (base, max_exponent):

• max_exponent >= 32 rejected with max_exponent (%d) >= max_exponent_upperbound (%d)
• base^max_exponent >= 2^32 rejected with base^max_exponent (%f^%d) should be less than 2^32

The bound itself is spelled differently on each side: common/countdown owns the const maxExponentUpperbound uint8 = 32, while params/config_backfill.go uses the literal 32 twice.

#2831 demonstrates the cost of this duplication in practice: the same message-typo fix (")= >=" → ") >=") had to be applied twice, once per copy (c4e928b and 93b0673).

Where the shared check can live

params must not import common/countdown — that closes a cycle, because common/countdown → core/types → params already exists transitively (go list -deps verified). The reverse direction works: common/countdown may import params (also already true transitively).

So the shared validator belongs in params (or a lower package both sides import), with common/countdown delegating to it and keeping its own error messages if callers depend on the exact text.

Source

Found during the review of #2831 (the #2828 race fix). The duplication is pre-existing, not introduced by that PR.