portal: Reinstate checks for whether we can use an app-supplied fd - #6586

portal: Factor out a function to validate fds attached to D-Bus message

Previously, if one of the handles in sandbox-expose-fd or
sandbox-expose-fd-ro was out of range, we'd dereference error->message
while error was NULL, and crash. Instead, use a function that checks
for each error condition separately, and ends up with the error set
on any failure.

This intentionally doesn't check against validate_opath_fd, which we
do separately: we only want to do that for fds that are to be re-exposed
into a sandbox, but not for the app-fd, usr-fd or array of fds to inherit.

portal: Use peek_fd_for_handle for inherited fds, app_fd, usr_fd

These only need to check that the handle is in range, and don't need
to validate it as an O_PATH fd.

portal: Remove fds array and fds_len

Now that all accesses to the fd list are going through
peek_fd_for_handle(), we don't need this.

portal: Early-return if validate_opath_fd() fails

This pattern will allow us to add more checks after validate_opath_fd(),
but before actually using the fd.

portal: Reinstate checks for whether we can use an app-supplied fd

These were part of get_path_for_fd() before commit 3c50014
"portal: Use --bind-fd, --app-fd and --usr-fd options to avoid races".
If these checks would fail, then the equivalent in bwrap is also going
to fail, but we have the opportunity to provide better error messages
here.

For the /app and /usr fds, we always reported errors from these checks
as an error; continue to do so.

For the sandbox expose fds, a historical quirk of this code is that if
these checks failed, we would merely log at g_info() level and ignore
the request to expose the fd in the sandbox. With hindsight this was
probably not appropriate, but apps are relying on it now: for example,
org.gnome.Epiphany asks to expose files from /app and /usr in the
subsandbox. When we ignored those requests (because /app and /usr
have a different meaning on the host system), the app worked as
intended anyway, because the subsandbox has access to the app's /app
and the runtime's /usr whether they're explicitly added or not.

Helps: [Bug]: Epiphany crashing with Flatpak 1.16.5: bwrap: Can't find source path /proc/self/fd/79: No such file or directory #6584

portal: Bump up log level for inability to expose fds to warning

Ideally we probably want the apps that are affected by this to stop
passing paths below /app or /usr, or non-filesystem objects, to the
flatpak-spawn --sandbox-expose family of options: it's misleading
if the app explicitly tells us to expose a path in the sandbox, but
then we neither do so nor report a warning or error.