fix(db): race condition mdbx abort tx

[emhane]

Closes #6441.

• Adds a list for aborted rw transactions, which follows the pattern for read transactions. Checks if a transaction is already aborted before calling ffi::mdbx_txn_abort(tx_ptr).
• Changes method signature for adding aborted read transaction so that it returns whether or not the transaction was already present in the aborted list.
• Sets read transactions for TxnManager before starting message listener. Before message listener would always run with read transactions set to None. (cherry-picked to main already)
• Adds metrics for observing length of aborted list, from which entries are only removed if the "user tries to use" (or mdbx assigns when user opens new tx) this pointer again.

[shekhirin]

new_with_max_read_transaction_duration change is legit, I like it and believe it's fully implemented in #6809 now.

Regarding write transactions: we don't actually need to track them in any way, because we don't enforce any timeouts on them, and they can be running for however long they want. See bullet point 2 in #5228 for the reason why long-running read transactions are bad (and this is why we implemented a hard timeout on them).

[shekhirin]

Two main things:

1. ReadTransactions.aborted should only keep track of the transactions that were aborted due to a timeout, so we can check against it on MDBX_EBADSIGN and report a nice error.
2. We still don't know if MDBX re-uses transaction pointers, and it's important because my previous assumption was that it doesn't.

[shekhirin]

can you please explain this change?

[emhane]

it allows a txn ptr to be reused if mdbx deems it fit to reuse, i.e. error code is 0

[emhane]

if err_code == 0, but the txn stays in aborted txns, then aborting it will lead to Error::ReadTransactionAborted

[shekhirin]

if the error code is not MDBX_EBADSIGN (maybe even 0 which is success), why do we want to remove it from the list of aborted transactions? MDBX_EBADSIGN is what usually returned by MDBX in case when we close the transaction and someone tries to re-use it later

[emhane]

no wait got that mixed up.

txn is aborted because time out, makes mdbx say "hey this ptr can be assigned"
open "new" txn and mdbx uses that same ptr, so err code is 0, so that check fails already at err_code == ffi::MDBX_EBADSIGN
txn stays in aborted list
user tries to abort the "new" txn, gets Error::TransactionAborted, very confused user

[emhane]

makes more sense to change order of that guard I think, then to remove from the aborted list when user tries to abort by drop or by TxnManagerMessage

[shekhirin]

user tries to abort the "new" txn, gets Error::TransactionAborted, very confused user

why would that happen? If a user tries to abort a new transaction, it will go through the mdbx_txn_abort just fine and return a code 0, I think?

[emhane]

moved this to its own scope #6844

[emhane]

closed in favour of #6850 (review).