tx/rm_stm: fix handling of replay commit requests

[bharathv]

A commit replay can happen in the following cases for example:

1. Coordinator marked the tx as prepared, dispatched remote commit_tx and
   crashed. Recovers notices the transaction as prepared and attempts to
   roll forward the transaction (recommit).

2. Coordinator lost leadership as it was dispatching remote commit_tx,
   got frozen, a new leader takes over, commits and bumps the sequence
   number to start a new transaction. Meanwhile the original coordinator
   recovers from frozen state and starts retrying for a brief period
   (rare case).

Prior to this commit, in case of replayed commits, if the partition lost
the transaction state, it was rejecting the request as invalid. The
transaction state can be lost due to producer eviction or with the
sequence number advancing. This can result in a stuck transaction on the
coordinator (particularly in example 1) as it cannot be rolled forward
or back even with a higher producer epoch effectively resulting in a
unusable producer.

With this commit, if there is no local inflight transaction for the
given producer the partition simply assumes the transaction as committed
to make forward progress. This is a valid assumption for the following
reasons

1. The local transaction state is only evicted if the transaction is
   committed or aborted, so either of these must have happened.
2. The fact that there is a commit_tx() from a coordinator means we are
   guaranteed that the tx is "prepared" on the coordinator, so the only
   way it could've been sealed already was with an earlier commit_tx

Fixes: #19954
Fixes: #18184

Backports Required

• none - not a bug fix
• none - this is a backport
• none - issue does not exist in previous branches
• none - papercut/not impactful enough to backport
• v24.1.x
• v23.3.x
• v23.2.x

Release Notes

• none

[bharathv]

/ci-repeat 1
skip-units
dt-repeat=50 tests/rptest/transactions/transactions_test.py::TxUpgradeTest