Coordinator primary segment assignment fix

[clintropolis]

Fixes #5531 by taking segment loading into account when deciding how to place segments, avoiding a bug where primary assignment would assign the segment to all historicals until it is loaded.

Reverts some code removed in #4921 for tracking currently loading segments in SegmentReplicantLookup.

[jon-wei]

Fix looks good to me, would be nice if we had tests but looks like that's pretty difficult/complicated as of now

[jihoonson]

LGTM overall. Can we add a unit test to verify the load rule correctly considers segment loading?

[jihoonson]

Unnecessary lines.

[jon-wei]

LGTM after CI

[gianm]

Saw a failure in this one:

testMoveSegment(io.druid.server.coordinator.CuratorDruidCoordinatorTest)  Time elapsed: 6.71 sec  <<< ERROR!
java.lang.Exception: test timed out after 5000 milliseconds
	at io.druid.server.coordinator.CuratorDruidCoordinatorTest.testMoveSegment(CuratorDruidCoordinatorTest.java:369)

Being optimistic, I restarted the tests. Although this test does seem potentially related to this patch.

[clintropolis]

@gianm the test was added in #5528, and it also failed in a definitely unrelated PR where i increased the timeout so hopefully it will happen less often. I don't think it's because of a race condition with the curator test server used in the test because I ran it in a loop where it successfully passed ~720 times, with something like this

n=1; while mvn -q -Dcheckstyle.skip=true -Dpmd.skip=true -Dtest=io.druid.server.coordinator.CuratorDruidCoordinatorTest#testMoveSegment -pl server test; do echo "success: $n"; n=$[$n + 1];:; done

but I suppose it's possible it's still racy somewhere. Also possible is that travis just takes a bit longer than my local debug machine took to run the tests, which is why the increased timeout in the other PR.

[gianm]

The test passed after being restarted, so let's commit the patch.