@Override
  public Iterator<ReplicaId> getReplicaIterator() {
    replicaIterator = replicaPool.iterator();
    return otIterator;
  }
The dynamic success target is introduced mainly for following use case:
In the intermediate state of "move replica", when decommission of old replicas is initiated(but hasn't transited to
INACTIVE yet), the PUT requests should be rejected on old replicas. For frontends, they are seeing both old and new
replicas(lets say 3 old and 3 new) and the success target should be 6 - 1 = 5. In the aforementioned scenario, PUT
request failed on 3 old replicas. It seems we should fail whole PUT operation because number of remaining requests
is already less than success target.
From another point of view, however, PUT request is highly likely to succeed on 3 new replicas and we actually
could consider it success without generating "slip put" (which makes PUT latency worse). The reason is, if new PUTs
already succeeded on at least 2 new replicas,  read-after-write should always succeed because frontends are always
able to see new replicas and subsequent READ/DELETE/TtlUpdate request should succeed on at least 2 aforementioned
new replicas.
ambry-router/src/main/java/com/github/ambry/router/SimpleOperationTracker.java