File locking

Sqlite and the Emscripten cache file are two cases where file locking has come up in real-world use cases.

The POSIX way to do file locking, with fcntl and F_SETLK/F_GETLK-style locks has the unfortunate property of being per-process, which is unfortunate both for being contrary to what applications actually want, and because we'd prefer to avoid exposing details like which host processes things are running in to wasm programs. (POSIX is considering fixing this, but until they do and systems update to the new mechanism, we need to work with what current systems provide.)

Here are some notes on a WASI file locking API might want to consider:

• The API should support byte-range locks, but permit implementations to lock more than requested, potentially up to the whole file. For example, FreeBSD has fcntl locks with the unfortunate POSIX behavior, and flock with the desirable per-file-description behavior, however flock only supports locking whole files at a time.
• Discretionary file locking only is probably enough for now. Mandatory locking isn't reliably available in many host environments.
• A lock can be shared (multiple locks can be held at once) or exclusive (only one lock).
• Only one lock can be held on a given byte range of a given file description at a time.
• Locks can be upgraded from shared to exclusive.
• For now, acquiring a lock blocks until the lock is available.
• It may be useful to permit implementations to report that locking is unsupported on the host filesystem. Some old NFS implementations, and possibly other networked filesystems, don't support locking.

The issue contains design notes for a WASI file-locking API but names no implementation files, tests, or entry points. Start by reviewing the listed requirements and existing WASI API conventions. Done means the locking API design is agreed, including range, shared/exclusive, blocking, upgrade, and unsupported-filesystem behavior.