[LibOS] Add O_APPEND emulation for single process

[dimakuv]

Description of the changes

This PR adds O_APPEND emulation, but only within a single process.

Note that Gramine doesn't support multi-process operations on the same file anyhow, in particular, the file position is not synchronized among multiple processes. This PR doesn't change this limitation of Gramine, thus O_APPEND writes don't work correctly (may overwrite file contents).

Note that Linux has a bug in pwrite(). Gramine emulates this bug in the same way.

Fixes #1921.

See also:

• Future ideas for filesystem and multi-process synchronization #584
• [LibOS] O_APPEND during open() is not honored #1152

How to test this PR?

A new FS test is added. One LTP test is uncommented.

---

This change is 

[dimakuv]

Reviewable status: 0 of 18 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (1 more required), not enough approvals from different teams (1 more required, approved so far: Intel)

a discussion (no related file):
FYI: implementation of O_APPEND in the Linux kernel is very simple and self-contained. I searched for APPEND keyword and these are the main sources:

• https://elixir.bootlin.com/linux/v6.9/source/fs/fcntl.c
• https://elixir.bootlin.com/linux/v6.9/source/fs/namei.c
• https://elixir.bootlin.com/linux/v6.9/source/fs/open.c
• https://elixir.bootlin.com/linux/v6.9/source/fs/read_write.c

I hope I covered all Linux logic on O_APPEND in this PR. (Note that some logic was already implemented in Gramine.)

---

---

libos/src/fs/chroot/encrypted.c line 480 at r2 (raw file):

    lock(&hdl->inode->lock);

    file_off_t actual_pos = (hdl->flags & O_APPEND) ? hdl->inode->size : *pos;

I admit that I don't understand the locking in these handlers... Technically, O_APPEND flag may be changed at runtime via fcntl(SET_FL), so there must be smth like lock(&hdl->lock). At the same time, I don't observe such locking in other (similar) places, and it's also confusing what needs to be locked where.

So for now I do not perform additional locking. I even wonder if hdl->flags can be considered thread-safe for well-behaved apps, because if some app changes the flags in one thread and e.g. writes in another thread, that's a data race and a bug in the app.

---

libos/src/sys/libos_file.c line 445 at r2 (raw file):

    }

    if (!(in_hdl->acc_mode & MAY_READ) || !(out_hdl->acc_mode & MAY_WRITE)

FYI: this change is orthogonal to this PR. Surprisingly, there was already handling of O_APPEND in this sendfile emulation, though it returned an incorrect error code. So I fixed this and also added two other checks. This could be moved out to a separate PR if needed.

---

libos/test/fs/test_fs.py line 136 at r2 (raw file):

        self.assertIn('TEST 1 (' + file_path + ')', stdout)
        self.assertIn('TEST 2 (' + file_path + ')', stdout)
        self.assertIn('TEST 3 (' + file_path + ')', stdout)

FYI: Other FS tests also do things like self.assertIn(close(...)), but there are so many lines in the log, that I found it stupid to check each line. So just checking that sub-tests are at least started and printed out. And of course the whole test must run to successful completion.

[dimakuv]

Jenkins, test this please (Jenkins was dead when this PR was created)