The transaction API by default takes the write concern from the caller's opCtx and will commit its transaction using it. The default "run()" method will throw if either the commit command fails or it fails waiting for write concern. This can easily lead to converting a write concern error into a command level error, which can be a correctness issue if the transaction is run implicitly as part of another command. Instead, we should make the runNoThrow() method that returns a struct with both the command status and write concern status the only way to use the API, so callers are forced to consider the distinction between both kinds of errors.

Further, the API runs its commands on a separate client than the caller's, so "Client" level decorations, like ReplClientInfo (used to wait on write concern after a command finishes), aren't updated. The API tries to work around this by updating the OperationTimeTracker and ReplClientInfo lastProxyWriteTimestamp after running, but in the case where the API is used in a replica set command, this does not update the opTime used to wait for replication, which is just the ReplClientInfo lastOp. This makes it tricky to correctly handle write concern. The API should have an easy way to support this, e.g. a way to commit with a write concern that doesn't wait for replication and then lastOp on the caller's Client with the opTime of the commit, so after the caller's command runs it waits for write concern correctly.