Fix the potential race between SplittableInputSource.getNumSplits() and SplittableInputSource.createSplits() in TaskMonitor

[jihoonson]

Description

SplittableInputSource has two methods for parallel indexing. getNumSplits() returns the exact number of splits to process and createSplits() returns a stream of InputSplits. Even though they are pretty tightly related to each other, it's not recommended to cache all splits in memory because it could be big if there are too many input splits. However, if it doesn't cache, the number of splits from getNumSplits() and createSplits() can be different because some files can be created or deleted between calls.

getNumSplits() is currently used for 2 purposes in the parallel indexing task. First is to check that all subtasks of a phase has succeeded and second is to estimate the progress of each phase. This PR is to fix the bug above by changing getNumSplits() to getEstimatedNumSplits(). ParallelIndexingPhaseRunner will use the number of SubTaskSpecs that it has iterated and compare it against the number of succeeded subtasks to determine the end of the phase. For the phase progress, it will just use the estimated number of total splits which could be wrong but doesn't that harm.

---

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.
• 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.
• added integration tests.
• been tested in a test Druid cluster.

---

This change is 

[clintropolis]

this lgtm, but could you try to add a test to simulate a mismatch between estimated number of inputs and actual number of inputs processed where the outcome is still a success?

[jihoonson]

@clintropolis sounds good. Added unit tests.

[clintropolis]

lgtm 👍 thanks for adding the test

[jihoonson]

Probably the API change should be called out in the release notes.