Reroute eagerly on shard started events

We have an optimization where we try to delay reroute after we processed the shard started events to try and combine a few into the same event. With teh queueing of shard started events in places, we don't need to do it, and we can reroute right away, which will actually reduce the amount of cluster state events we send.

This will also have a nice side effect of not missing on "waitForRelocatingShards(0)" on cluster health checks since relocations will happen right away.

closes #3417
Query/Filter Facet should support 64bit counter, not 32
closes #3419
better failure message in test
cleamup ShardIter#reset method
don't have teh reset method return an instance, as it might confuse usage into thinking it might be a different instance
If no mapping can be found for value field, throw a proper exception.
Made use of the static client() method instead of the client field.
Run refresh before executing non realtime get
Take fragile test out of the loop

UpdateNumberOfReplicasTests#simpleUpdateNumberOfReplicasTests is very
fragile due to executing searches based on dated knowledge of
the cluster state and calling shards that have been relocating away in
the mean time. A fix is on the way.
Modified test to make failures clearer

Added shard failure check when sorting on unmapped field, could be any SearchPhaseExecutionException otherwise (e.g. missing shards)