Currently, when fetching an active transaction, we don't set the result.state for in-progress transactions. This can be a problem for when we abort transactions on step-up. In that situation, we get the state of the ActiveTransactionHistory to be kNone which will cause the txn state to be set to kExecutableRetryableWrite.

This can cause problems where we don't log metrics for transactions since the participant thinks it is a retryable write.

Additionally, when this is fixed, it is possible to trigger an invariant in scenarios like in abort_in_progress_transactions_on_step_up.js. In this test, a node steps up from secondary to primary with an in-progress transaction already in place. This transaction was replicated from the last primary, and the node knows to abort it. However, in scenarios where the transaction is slow, we will try to log that transaction metric and hit the invariant since the startTime was never set on the secondary.