Load getTaskLocation on task startup in mmless ingestion

[georgew5656]

Fixes a bug with mmless ingestion when overlord leadership is rolled over.

Description

When a overlord newly attains leadership in a cluster running mmless ingestion, it will load all the running tasks from kubernetes, but not the value of taskLocation. taskLocation is populated the first time getTaskLocation() is called on each task.

The problem with this is getTaskLocation is called in the serviceLocator.locate() method, which runs under the ServiceClientFactory thread pool and is not supposed to make a lot of network calls. Frequently the first caller (before taskLocation is cached) is a supervisor trying to contact its tasks. If there are many supervisors and kafka tasks running in the cluster, the ServiceClientFactory threads can get stuck trying to call locate() (since the function will block on reaching out to k8s for the pod ips).

Fixed the bug ...

Renamed the class ...

Added a forbidden-apis entry ...

Since we don't actually need to update taskLocation (the pod IP is static through the lifetime of a k8s pod and we don't retry jobs), we can just load taskLocation right after the pod has started (in the join method).

Release note

• fix bug with mmless ingestion in high scale clusters

Key changed/added classes in this PR

• KubernetesPeonLifecycle

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]

Could you run a test to measure the impact this has on an overlord leadership change a cluster with 100s of running tasks. If this impact is minimal, then I think this is a good change and the suggestion below can be done in another patch if needed.

An alternative approach could be to update the TaskAdapter interface to create a task from a Pod instead of relying on a Job. That would mean you would not need to add a call per task to k8s get the pod after already calling k8s to get all the peon jobs.