SOLR-17971: Fix REBALANCELEADERS wait when the Overseer is disabled

[sarkaramrit1993]

https://issues.apache.org/jira/browse/SOLR-17971

With the Overseer disabled, REBALANCELEADERS always waited the full maxWaitSeconds (60s by default) and then logged a timeout. The leaders still moved. waitAsyncRequests() only looked for sub-command results in the Overseer completed/failure maps, but in distributed mode those results go to DistributedApiAsyncTracker. Because of that, the ids were also never cleared and piled up under /distributedapi/async/persistent.

Changes:

• waitAsyncRequests() now checks the store for the current mode, same branching as REQUESTSTATUS in ClusterCommands. In distributed mode, deleteSingleAsyncId() both tells us the task is done and removes it.
• Overseer path behaves the same, just drops the extra contains() before remove().

Not changed: I went with the tracker directly instead of issuing a REQUESTSTATUS call per id as the JIRA suggests. It's the same lookup without the extra request.

Tests: new testRebalanceLeadersClearsAsyncIds in TestRebalanceLeaders asserts no rebalanceleaders_ ids are left in either store and the call returns before the timeout. Without the fix and the Overseer disabled, it fails with 29 leftover ids. Ran the full class with -Ptests.nightly=true in both modes, plus gradlew check -x test.

[dsmiley]

Looks good!

The fix branches on the mode the same way REQUESTSTATUS does in ClusterCommands

Then maybe the logic should be centralized? (didn't check how elegant this is)

[sarkaramrit1993]

Good call, done. Both REBALANCELEADERS and DELETESTATUS now go through ZkController.removeStoredAsyncResponse(asyncId). The REQUESTSTATUS lookup and delete-all paths still do their own branching. Nothing else duplicates them, so I left those alone.