kv: allocator should apply all span config changes proactivily

[andrewbaptist]

Describe the problem

When a span config change is made it should apply immediately. In some cases the cluster waits until the system has scanned through to find the range instead of applying it immediately.

To Reproduce TODO: This has not been tested yet, but reported by a customer

• Create a table with minimal data in it but a number of splits (e.g. 1000)
• Change the replication factor to 5.
• Notice that not all the ranges change to RF=5 immediately, most do, but some take up to 10 minutes to change.

We should first create a test that replicates this behavior.

Expected behavior We should be reactive to span config changes and apply all the changes immediately.

Jira issue: CRDB-38886

Epic CRDB-39952

[arulajmani]

When a span config change is made it should apply immediately. In some cases the cluster waits until the system has scanned through to find the range instead of applying it immediately.

We spoke about this in one of our meetings, so I'll capture the discussion here as well for others. The expectation is that this should already happen. See:

https://github.com/cockroachdb/cockroach/blob/3b969e3f0be88c9c81417bb4e40a06d464d65f11/pkg/kv/kvserver/store.go#L2550-L2552

@andrewbaptist mentioned that anecdotally, he's seen rare cases when this doesn't happen. We should clarify these.