Currently, the coordinateCommitTransaction command sets its client opTime to the system latest to guarantee it waits for a time at least as great as the time the decision was written at. When true, the coordinateCommitReturnImmediatelyAfterPersistingDecision server parameter lets coordinateCommitTransaction return as soon as the decision is written locally, so this allows respecting a user's write concern weaker than majority. As of SERVER-63971, that parameter is false by default, so now coordinateCommitTransaction only ends after the coordinator has received decision acknowledgements from all shards. The decision is sent with majority write concern, so coordinateCommitTransaction has effectively already waited for majority write concern, but will still set its client opTime forward, and likely end up waiting for majority write concern again.

This means in the normal case, a two phase commit transaction will wait for 5 sequential majority replications:
1. Coordinator writing the participant list
2. Participants applying prepareTransaction
3. Coordinator writing the decision
4. Participants applying the decision
5. Coordinator waiting for system last opTime before returning from coordinateCommitTransaction

The final wait is after the transaction has majority committed on all participants, so instead coordinateCommitTransaction should return immediately (as long as the user's write concern isn't stronger than majority). A possible fix is for the transaction coordinator to return an opTime for coordinateCommitTransaction to wait on, instead of having the command use the last system opTime.