Add advisory file locking support.

[sunfishcode]

Add functions which correspond to flock in Unix. This is not a POSIX interface, but it's sufficiently portable, there's a way to implement it on Windows, and it doesn't have problematic process-associated locks.

Instead of having a single flock function that gets passed and enum, this has separate functions for shared vs. exclusive, and locking vs. non-locking. That's something we can revisit if needed, but it keeps the API simpler for now.

[bjorn3]

Trying to lock a file in one mode and then locking in another mode inside the same process (not wasm instance!) will silently switch the lock mode even if as I understand it the locking was done through a different fd. In addition this switching is not guaranteed to be atomic. Flock also doesn't work on NFS. Finally it is not clear to me how handling multiple locks for the same file in the same process is supposed behave.

Maybe the best way would be to have a clean slatw design for wasi and have wasi runtimes emulate the right semantics using for example hidden files in combination with a single tightly controlled process global advisory or mandatory lock for the purpose of crash recovery. Or something like that.

[sunfishcode]

Trying to lock a file in one mode and then locking in another mode inside the same process (not wasm instance!) will silently switch the lock mode even if as I understand it the locking was done through a different fd. In addition this switching is not guaranteed to be atomic.

Linux's flock documentation says "If a process uses open(2) (or similar) to obtain more than one file descriptor for the same file, these file descriptors are treated independently by flock()." In my experiments, FreeBSD's flock has this behavior too.

Flock also doesn't work on NFS.

It is emulated to some degree on some platforms, though there are caveats. But my overall idea is, the fact that some people want to use an API not designed to be used over networks, over networks, shouldn't mean that everyone else can't have nice things 😄. I'll add some documentation about this.

Finally it is not clear to me how handling multiple locks for the same file in the same process is supposed behave.

Linux documents that flock locks are per file-description, and not per-process. FreeBSD's appear to behave the same way.

Maybe the best way would be to have a clean slatw design for wasi and have wasi runtimes emulate the right semantics using for example hidden files in combination with a single tightly controlled process global advisory or mandatory lock for the purpose of crash recovery. Or something like that.

We can do that if we need to, but my sense here is that flock is sufficient.

[sunfishcode]

I've now tried an experiment on NFS on Linux, where the man page says that fcntl is emulated using fcntl when on NFS, and it still has per-file-description semantics, rather than per-process.

[sunfishcode]

To protect users from silent data corruption, I've added a note that implementations should know whether the filesystem they're on supports locking or not, and if not, they should make the lock functions here fail with ENOSYS.

[bjorn3]

fcntl(F_SETLK) is process-global, which is cursed. Linux also has fcntl(F_OFD_SETLK) which has the same semantics as flock wrt to multiple fds in the same process. I presume glibc uses the latter to emulate flock on NFS.