kvserver: cpu doesn't balance quickly after a workload step change

When the workload exhibits a step change, such as a 5x increase in load, dropping tables and re-creating them with a workload at the same rate, or dropping the load, CPU has been observed to take up to 20 minutes to equalize.

The suspected cause is that CPU load based rebalancing is backed by a sliding window per-replica, which records the last 30 minutes of CPU usage on this replica, in 6 x 5 minute buckets.

https://github.com/cockroachdb/cockroach/blob/953d09cce5a01cc0053e138516d80a27454f027c/pkg/kv/kvserver/replicastats/replica_stats.go#L22-L29

The buckets are aggregated using the arithmetic mean, before rating, which therefore equally weights CPU usage from 25 minutes ago, as usage from less than a minute ago.

This issue will be closed when this behavior no longer exists, either with default or non-default settings.

Useful Resources

Related issues:
- https://github.com/cockroachdb/cockroach/issues/87187
- https://github.com/cockroachdb/cockroach/issues/104292 (thrashing is a large reason why a larger window size was likely introduced in the first place)
- https://github.com/cockroachdb/cockroach/issues/83129
- https://github.com/cockroachdb/cockroach/issues/107890

Related code:

https://github.com/cockroachdb/cockroach/blob/953d09cce5a01cc0053e138516d80a27454f027c/pkg/kv/kvserver/load/replica_load.go#L21-L24

https://github.com/cockroachdb/cockroach/blob/953d09cce5a01cc0053e138516d80a27454f027c/pkg/kv/kvserver/replicastats/replica_stats.go#L279-L283

Also see:
- http://dimacs.rutgers.edu/~graham/pubs/papers/fwddecay.pdf
- https://cockroachlabs.slack.com/archives/G01G8LK77DK/p1729001296821899

Jira issue: CRDB-43271

Epic CRDB-56265