If a transaction aborts due to reasons other than an explicit abortTransaction command (e.g. writeConflict errors), we could still hit this which would call setLastOpToSystemLastOpTime and waitForWriteConcern unnecessarily.

There is also a weird behavior where if the same connection is used outside of transaction, abortTransction would also wait for writeConcern for the lastOp set by the same connection in previous writes done outside of the transaction (see this test). This is because wasGlobalLockTakenForWrite would always be true when aborting a transaction (either through abortTransction command or due to transaction errors).