If an I/O error occurred during write(), the dirty page tracking would
leak causing a panic when the transaction was committed/aborted

This fixes a cache poisoning issue in which a page might be in the
userspace cache after walking the btrees during crash recovery, but then
be freed by the rollback process of recovery. This could then poison the
cache, leading to a crash in the future

Fixes a page leak if an I/O error occurred during commit(), since drop()
would still flush the recovery bit to "clean"

Fixes a corruption issue that could occur if a Durability::None commit
was made, followed by a durable commit, and the durable commit crashed
during the call to commit().

Non-durable commits pushed their pending free pages into the freed
table. The next durable commit then processed these *before* finalizing
its commit. If that durable commit crashed after processing the frees,
but before finalizing, then all the non-durable commits are rolled back,
but the freed pages have already been processed. This left the database
in a corrupted state since those pages could get overwritten as part of
finalizing the durable commit

An I/O error during writeback could cause the page being flushed to be
lost

The root would end up set, but not the path, this lead to a panic in the
drop() method

Every issue found has reproduced at < 10k, and the corpus only has items
up to ~50k

If an I/O occurring during commit(), the transaction would then try to
abort() which might panic since the data structures are left in an
inconsistent state