I'm trying to make more use of `cap-std` in our stack, and
this will be a key enabling API.
Actually a notable side benefit of this is that we don't need
to teach the ostree C code itself to use `openat2`, we inherit
cap-std's setup.
All of the internal ostree code using the prior `openat()` should
continue to work.
I only did basic sanity checking of this; there may be bugs
in other APIs.
The fact that the uid/gid/mode are big endian bit me when I was
trying to parse this "by hand" in ostree-rs-ext.
Let's add a footgun-free API for this.
(And yeah, we should probably do the same for the other variant types)
The `resolve_rev` C method should really have been
`resolve_rev_optional` from the start - it is more obviously wrong
in Rust because the input parameter `allows_noent` controls
whether the returned `Option` can ever be `None`.
I debated adding this to the C bindings, and may still do so,
but eh it's faster to write + ship in Rust, and the future of ostree is
Rust anyways.
An intimidating spam of compiler errors at the start, but the
biggest was handling the new convention of `ostree_sys::` => `ffi::`.
This will require a semver bump of course.
Colin Walters
Felix Krull