Batch segment deletes triggered by DropRules

[kfaraz]

If several segments become eligible for a DropRule in a single coordinator run, multiple metadata update statements are fired which could have potentially been batched.

Changes:

• Collect segment delete operations in StrategicSegmentAssigner during RunRules duty
• Perform batch delete for each datasource at the end of RunRules duty
• Move collection of some stats from CollectSegmentAndServerStats to the respective duties generating those stats for clarity
• Clean up SqlSegmentsMetadataQuery API for marking segments as used/unused
• Add basic simulation test for Coordinator runs
• Add simulation test to verify that segment moves are cancelled if the target server disappears

Classes to review:

• DruidCoordinator
• CollectSegmentAndServerStats
• StrategicSegmentAssigner
• RunRules

---

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[kfaraz]

Batching doesn't seem to mitigate the problem either as the real problem here is contention while acquiring a connection. I guess we should perform the deletes asynchronously. I will update this PR accordingly.

[kfaraz]

Closing this in favor of #14644 .