Support idmapped mounts, and give absent caller ids a type

CHANGELOG.md

@@ -1,6 +1,24 @@
 # FUSE for Rust - Changelog
 
 ## Unreleased
+* **Breaking:** `Request::uid()` and `Request::gid()` return `Option<u32>`. An idmapped mount
+  has no caller ids to report, so there is not always a uid. A filesystem that does not request
+  `InitFlags::FUSE_ALLOW_IDMAP` is always given ids and can unwrap
+* **Breaking:** `mknod()`, `mkdir()`, `symlink()`, `create()` and `tmpfile()` take an `Owner`
+  argument, which is who the inode they create belongs to, and `rename()` takes an
+  `Option<Owner>` for the inode a `RENAME_WHITEOUT` leaves behind. Those are exactly the requests the
+  kernel sends ids for, and on an idmapped mount the owner is the caller's ids mapped through
+  the mount's idmapping rather than the ids themselves, so reading it off the request would
+  have been wrong
+* `KernelConfig::add_capabilities()` now accepts `InitFlags::FUSE_ALLOW_IDMAP` (ABI 7.41),
+  which lets the mount be idmapped. It is accepted only where it can be honored - the session
+  must allow other users, and `default_permissions` must be in force, whether from
+  `MountOption::DefaultPermissions` or from negotiating `InitFlags::FUSE_POSIX_ACL` - and
+  refused otherwise: the kernel refuses the connection outright without `default_permissions`,
+  and without allow_other fuser would be offering an owner-only ACL it can no longer enforce. Once negotiated the kernel withholds the
+  caller's ids from every request that does not create an inode, so `Request::uid()` and
+  `Request::gid()` report the new `FUSE_INVALID_UIDGID` there; the requests that do create an
+  inode still carry ids, and they are the owner the new inode should get, already mapped
 * Add `Filesystem::statx()`, which the kernel calls for `statx(2)` (ABI 7.38), along with
   `StatxAttr` and `ReplyStatx`. This exists to report a creation time, which no other request
   can carry: `fuse_attr` has a field for it on macOS alone, so on Linux `statx(2)` otherwise