When running with multiple consistency modes simultaneously transactions can currently be assigned the same timestamp

Saw this in a release build on a 10 node cluster while running YCSB with multiple consistency modes at the same time.

In mvcc.cc we assign timestamps either from the current clock value, Now() or the latest clock value NowLatest() depending on the consistency mode, while each of them are independently monotonically increasing their combination is not. That is if we have TX1 (commit wait consistency) be assigned a ts at now + error, say 15, and later on TX2 (no consistency) is also assigned 15 we have two transactions with the same timestamp.

The problem is that whenever one commits the timestamp gets removed from the in-flights and when the other commits the make-sure-the-tx-is-on-the-in-flights check fails.

This only happens in release builds, since the CHECK whenever we can't insert into the in-flights is a DCHECK, but the problem is always there.

The solution seems to be simple: keep getting timestamps until we get one that is not on the in-flights.

However this still leaves the door open for multiple transactions with the same timestamp (if they were not in the in-flights at the same time). Thoughts on whether this is a problem?