revlog: improve the robustness of the splitting process The previous "in-place" splitting, preserving the splitting on transaction failure had a couple of issue in case of transaction rollback: - a race windows that could still lead to a crash and data loss - it corrupted the `fncache`. So instead, we use a new approach that we summarized as "we do a backup of the inline revlog pre-split, and we restore this in case of failure". To make readers live easier, we don't overwrite the inline index file until transaction finalization. (once the transaction get into its finalization phase, it is not expected to rollback, unless some crash happens). To do so, we write the index of the split index in a temporary file that we use until transaction finalization. We also keep a backup of the initial inline file to be able to rollback the split if needed. As a result, transaction rollback cancel the split and no longer corrupt fncache. We also no longer have a small inconsistency windows where the transaction could be unrecoverable.

fncache: make it possible to ignore some file In the next changeset, we need to able to ignore some temporary file. This changeset teach the fncache about that.

revlog: test that pending hooks properly see the repository on split This seems important to explicitly cover this case before changing the code.

revlog: test possible read race condition with splitting This is currently working fine, but could break with another approach (for example, with the one we are about to use in the next changesets…) So we make sure the case is covered.

revlog: add a failing variant of the the split + transaction test We have another variant to tests, and it is crashing… So lets cover it with tests.

revlog: update the split + transaction test We add section, increase the amount of comments and simplify some of the constructs. We are about to build more on top this tests so lets do a small cleanup first.

transaction: allow to backup file that already have an offset This will be useful in the next changeset to deal with rolling back the split of inline revlog on transaction failure. This involve deeper change to the transaction logic as we need to make sure we restore the backup -before- the truncation step. Otherwise, the truncation would act on the wrong file and be overwritten by the backup restoration later.