In SERVER-37121, instead of crashing when a commit_timestamp races with the oldest/stable timestamp for the "ready: true" write of a secondary background index build, we changed the behavior to retry.

I incorrectly thought a transaction could be timestamped with a new value if the old one raced with constraints such as the stable_timestamp. However, a failure to timestamp a transaction requires redoing the whole transaction.

Note WT does not return a WT_ROLLBACK error code in this case, which presumably would have resulted in a WriteConflictRetry exception being thrown. Instead WT returns their generic error code.