allocator: reduce memory churn

The amount of memory the allocator uses scales linearly with the number of stores being considered. In a cluster with many stores, the memory churn can lead to GC pressure which results in increased time spent collecting and potentially scheduler contention.

See the screenshot taken below of the recent allocations (5s) on a node in a 60 node cluster:


**Describe the solution you'd like**
Wrapping `rankedCandidateListForRebalancing` and `StoreList` in a sync pool would get a lot of mileage.

**Extra Context**

Note the multi-metric allocator, allocator2 already does most of this. An approach which can be backported to 23.1 and potentially 22.2 would be ideal.

Jira issue: CRDB-28996

Epic CRDB-41111