kvserver: update store pool for leasequeue.process

Previously, the lease queue didn’t update the local store pool correctly because
`AllocationTransferLeaseOp.ApplyImpact` was unimplemented. This wasn’t an issue
for the replicate queue, as it updates the local store pool directly through
`rq.TransferLease` by calling `UpdateLocalStoresAfterLeaseTransfer`. This patch
addresses the issue by calling `UpdateLocalStoresAfterLeaseTransfer` after
`replica.AdminTransferLease` inside the lease queue.

This fixes a bug where the allocator may make rebalancing decisions based on
stale store pool data, failing to account for recent lease transfers not yet
reflected in gossip. This state should eventually be corrected when real store
capacity is measured and gossiped, and store pools are refreshed.

This bug was found when reading the code.

Epic: none
Release note (bug fixes): Fixed a bug present since v24.1 where the allocator
could make rebalancing decisions based on stale data, failing to account for
recent local lease transfers not yet reflected in store capacity or gossip.

Author: wenyihu6

pkg/kv/kvserver/lease_queue.go

@@ -139,7 +139,15 @@ func (lq *leaseQueue) process(
 		if err := repl.AdminTransferLease(ctx, transferOp.Target.StoreID, false /* bypassSafetyChecks */); err != nil {
 			return false, errors.Wrapf(err, "%s: unable to transfer lease to s%d", repl, transferOp.Target)
 		}
-		change.Op.ApplyImpact(lq.storePool)
+
+		// TODO(wenyihu6): Initially, change.Op.ApplyImpact was used here. This was
+		// a problem since AllocationTransferLeaseOp.ApplyImpact was left
+		// unimplemented. We should either implement
+		// AllocationTransferLeaseOp.ApplyImpact correctly or remove the use of
+		// ApplyImpact entirely. The replicate queue does not have this issue since
+		// it uses rq.TransferLease, which updates the local store pool directly.
+		lq.storePool.UpdateLocalStoresAfterLeaseTransfer(
+			transferOp.Source.StoreID, transferOp.Target.StoreID, transferOp.Usage)
 	}
 
 	return true, nil