A shell of its former self remains which informs any potential user
about the removal.

The Device portal is, to the best of our knowledge, not used by any
component. It's also weird because it's not a portal expoed to clients
which caused confusion.

The service it provides is also provided by the permission store, minus
the ability to map from arbitrary PID to an app id. This PID to app id
mapping isn't something that can be done in general and is most likely
broken when the PID is not of the xdg-dbus-proxy.

One was a left-over and for the other we just removed the last users.

This will become useful once we support the dbus Containers1 interface
and a new XDP_APP_INFO kind can still refer to a flatpak.

…fo_sync

This will make it easier to follow which method of identiying an app
will be used under what conditions.

Instead of returning either NULL with error, NULL without error and
non-NULL without error, adhere to GLib convention and return either TRUE
with an out param set or FALSE with an error set.

The org.fdo.DBus.GetConnectionCredentials method gives us both a PID
(ProcessID) and a pidfd (ProcessFD) in one roundtrip. It fails when the
PID can't be retrieved but allows the pidfd to be -1.

The pidfd will become useful for host and Containers1 clients later.

Returns a GVariant containign all the metadata that a container engine
like flatpak has set on the socket for this app instance. This contains
the container type, app id, instance id and additional arbitrary
metadata such as the desktop file name.

If the D-Bus broker doesn't support the Containers1 interface or the app
using the portal is not running in a container, we fall back to the
other ways of identifying apps.

This specifically means it's safe to run a D-Bus broker which supports
Containers1 while flatpak doesn't. Eventually we want to remove the
flatpak and snap specific paths at which point it's a requirement to
have a Containers1 capable flatpak.

Both host apps and Containers1 apps can do pid mappings via pidfd. This
is some prep work for that.

Do some best effort pid remapping for host apps. This will only work
when the D-Bus broker supports pidfd (ProcessFD).

This new app kind is authenticated by D-Bus and x-d-p gets all the
information about the app from D-Bus which itself get the information
from the sandbox engine which set up the sandbox of the app.

Currently only flatpak and dbus (dbus-daemon) supports this mechanism
but it can be supported by any other sandbox engine, such as snap and
firejail.

This also means that an app with XDP_APP_INFO_KIND_CONTAINERS1 can still
be a flatpak or a snap app.

The goal is to make as many paths in x-d-p agnostic to the actual
sandbox engine and handle all XDP_APP_INFO_KIND_CONTAINERS1 apps the
same. Eventually we can then remove any other XDP_APP_INFO_KIND
variants.

This commit sets up a XdpAppInfo object with all the metadata x-d-p will
need. The follow up commit implements various XdpAppInfo
functionalities.

Uses some of the metadata from Containers1 directly and falls back to
the flatpak path in some cases.

Some of the fallbacks can be removed once the D-Bus broker supports ACL
and we can get rid of xdg-dbus-proxy.

The path remapping and tryexec functionalities are not implemented right
now.