Rename crash conssistency

[OmSaran]

There appears to be a bug in rename atomicity in SplitFS.

Occurs in the following sequence of operations:

1. Create file1
2. Create file2
3. rename file1 -> file2

SplitFS does the following during recovery:

1. Re-create file1 (since after rename file1 is lost)
2. Do nothing since file2 exists
3. Skip rename (step 3) since file2 exists.

End state of the filesystem leaves it in an inconsistent/non-atomic state where file1 and file2 exist after recovery while file2 only exists before recovery.

[OmSaran]

It can be reproduced with a program like this:

renam.c

#include <stdio.h>
#include <fcntl.h>
#include <assert.h>
#include <unistd.h>
#include <string.h>

#define FILE1 "/mnt/pmem_emul/file1.txt"
#define FILE2 "/mnt/pmem_emul/file2.txt"

void prep_file(const char * name, int num) {
    char buf[] = "filex.txt";
    int ret, fd;

    buf[4] = num + '0';
    
    remove(name);

    fd = open(name, O_WRONLY | O_CREAT, 0644);
    assert(fd > 0);
}

int main() {
    prep_file(FILE1, 1);
    prep_file(FILE2, 2);

    rename(FILE1, FILE2);
    _exit(2); // crash the program without flushing the op/append logs.
}

After the program execution, but before recovery, we see the following file: file2.txt only.
After the program execution and after recovery, we see the following files: file1.txt, file2.txt