calculatePendingRanges no longer safe for multiple adjacent range movements

  a534b2 adds tests that reproduce both bugs. bb36cd fixes the newly discovered bug ( test1Leave1Move in a534b2 ). There, the failure happens because for the same pending range we can include 2 replicas with the same endpoint and different ranges (violation of PendingRangeMaps Conflict.DUPLICATE policy). This happens because right now we include in PendingRangeMaps the entire new replica after leave for leave-affected ranges and only the pending part of it for move-affected ranges. This commit marks as pending only the missing part of the new replica. a33b03 solves the original issue. Without this commit getPendingRanges can fail if the same replica covers more than 1 pending range. I think that this is a valid situation. Consider testLeave2 in a534b2 . In this case replica Full(127.0.0.1:7012,(-9,0]) covers 2 ranges - (-9,-4] and (-4,0] . If we run the same test against 3.11 (-9, 0] is represented as {{ {(-9, -4], (-4, 0]} }} and that possible representation would not trigger the bug in 4.0. However, I think that we should not base safety of getPendingRanges execution on the way a particular AbstractReplicationStrategy represents a range and we should allow duplicate entries while building pending RangesAtEndpoint .