Datasource based exemption from deprioritization

[aruraghuwanshi]

Description

As of today tthere isn't a way to define high/low priority datasources. There are situations where we want to deprioritize queries based on the already present time based thresholds, but its possible that the druid cluster might host datasources that are higher in priority compared to others. For this reason, I've added another Optional json parameter exemptDatasources, which would host those high-priority datasources, which will skip the deprioritization logic entirely if the query being executed hosts any of the exempted datasources.

Updated the class ThresholdBasedQueryPrioritizationStrategy.

This PR has:

• [x] 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.
• [x] been tested in a test Druid cluster.

[maytasm]

Just my 2c,

• If it's possible, having this as a dynamic config like Coordinator/OVerlord dynamic config would be useful. Often time we find that important query/datasouce was put into the low lane and we need to switch it back to high lane ASAP
• An opposite of this would be useful to. Forcing datasource into low lane. Often time we find that bad/expensive query/datasouce starts coming in that, although not exceeding the threshold, is very very expensive CPU-wise (due to some query shape that was not captured in the current threshold settings)