Paxos ballot in StorageProxy could clash

This code in StorageProxy.beginAndRepairPaxos() takes a timestamp in microseconds but divides it by 1000 before adding one. So if the summary is null, ballotMillis would be the same for up to 1000 possible state timestamp values:

    long currentTime = (state.getTimestamp() / 1000) + 1;
    long ballotMillis = summary == null
                                 ? currentTime
                                 : Math.max(currentTime, 1 +    UUIDGen.unixTimestamp(summary.mostRecentInProgressCommit.ballot));
    UUID ballot = UUIDGen.getTimeUUID(ballotMillis);

state.getTimestamp() returns the time in micro seconds and it ensures to add one microsecond to any previously used timestamp if the client sends the same or an older timestamp.

Initially I used this code in ModificationStatement.casInternal(), introduced by CASSANDRA-9160 to support cas unit tests, but occasionally these tests were failing. It was only when I ensured uniqueness of the ballot that the tests started to pass reliably.

I wonder if we could ever have the same issue in StorageProxy?

cc jbellis and slebresne for CASSANDRA-7801