server: consider removing the decommission nudger

[miraradeva]

The recently-added decommission nudger (#130117) is responsible for periodically enqueuing ranges with decommissioning replicas to the replicate queue. However, we have seen in recent escalations that, in cases of a lot of pending replicate queue actions, such replicas still block decommissioning; the replicas stop doing so only after being manually (via the DB console) enqueued to the replicate queue.

We have an issue (#148090) to have better visibility into whether the nudger is doing its job, but assuming it is, the way it enqueues replicas still differs from the manual enqueueing:

• The nudger enqueues the replica via AddAsync, with a mid-level priority corresponding to AllocatorReplaceDecommissioningVoter. Then the replica waits for its turn to be processed.
• The manual enqueuing (with or without skipShouldQueue) calls store.Enqueue with async=false, and the replica is processed directly.

We should consider either changing the priority associated with AllocatorReplaceDecommissioningVoter, or allowing the nudger to process replicas (more) directly.

Companion issue: #148090.

Jira issue: CRDB-52839

[tbg]

Repurposing this issue to track removal of the nudger, since the work referenced in #153062 should have helped make decommissioning succeed more predictably. We should keep the nudger around for a little longer thought to see what remains of the "slow decommission" issues.