The PrepareConflictTracker uses an atomic boolean to indicate that a client is waiting on a prepare conflict, but that does not actually protect the _prepareConflictDuration from being concurrently written to and read from.

In addition to fixing this race, presumably by using another atomic variable, also make sure that the endPrepareConflict code is a no-op (and does no atomic operations) for cases where there were no prepare conflicts. This is needed because this code is executed for every storage engine level read operation and is therefore very hot, and shows up in profiling information.