Batch kill in azure

[georgew5656]

Description

Implement batch kill in azure to speed up segment killing.

I ran a quick test with 50k segments and kill sped up from 35 mins to ~2 minutes.

Fixed the bug ...

Renamed the class ...

Added a forbidden-apis entry ...

I tried to keep this implementation analagous to the S3DataSegmentKiller. I used the azure batch api to do this. One thing I had to do was ignore the descriptor.json files but I think this is okay because those were discontinued in 2019 and the azure extension was made core in 2020. If someone happens to have segments with descriptor.json from that period the descriptor.json will be left in deep storage and have to get killed manually.

I think this is worth it because otherwise I would have to fire off 2x as many batches to azure to delete all the descriptor.json files which generally don't exist. These failed requests also mess up the logs.

Release note

Speed up killing of segments in azure

Key changed/added classes in this PR

• AzureDataSegmentKiller
• AzureStorage
• TheirBaz

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.

[suneet-s]

Mostly looks good. 1 clarifying question

[suneet-s]

I tried tracing the code to understand when azureStorage#batchDeleteFiles can throw a runtime exception, but couldn't figure it out. Can you elaborate on when that is possible and why we would want the data segment killer to re-throw the runtime exception instead of wrapping it in a SegmentLoadingException. The interface says a SegmentLoadingException should be thrown if there is an issue with deleting the segments.

Suggested change

	@Test(expected = RuntimeException.class)
	@Test(expected = SegmentLoadingException.class)

[georgew5656]

I tried tracing the code to understand when azureStorage#batchDeleteFiles can throw a runtime exception, but couldn't figure it out. Can you elaborate on when that is possible and why we would want the data segment killer to re-throw the runtime exception instead of wrapping it in a SegmentLoadingException. The interface says a SegmentLoadingException should be thrown if there is an issue with deleting the segments.

it could potentially throw a exception when trying to construct the client (before making the requests to azure), those exceptions would not get caught and should propagate up. it's probably not that common of a scenario though