pressure-vessel: Add experimental code path for Flatpak sub-sandboxing

Requirements

• a non-setuid bwrap executable, and a kernel that allows the non-setuid bwrap to create new user namespaces
  • good: Debian 11/testing/unstable, Ubuntu, Fedora, Arch Linux default kernel with bubblewrap
  • bad: Debian 10 or older, SteamOS 2, Arch Linux linux-hardened with bubblewrap-suid
• some Flatpak branches that have not been reviewed and merged yet (infrequently-updated integration branch: https://github.com/smcv/flatpak/tree/for-pressure-vessel)
  • https://github.com/flatpak/flatpak/pull/4125
  • https://github.com/flatpak/flatpak/pull/4126
  • https://github.com/flatpak/flatpak/pull/4093
  • https://github.com/flatpak/flatpak/pull/4018
• the patched flatpak-portal running or D-Bus-activatable, and able to find the patched flatpak in PATH
  • PATH="${builddir}:$PATH" "${builddir}/flatpak-portal" -vr might work
• ${builddir}/flatpak override --user --allow=per-app-dev-shm --allow=per-app-tmp com.valvesoftware.Steam
• com.valvesoftware.Steam launched by the patched flatpak
• Run Steam with PRESSURE_VESSEL_FLATPAK_PR4018 in the environment (deliberately undocumented) to opt-in to the new code path

You will probably want to run with all the debug runes: G_MESSAGES_DEBUG=all, PROTON_LOG=1, STEAM_LINUX_RUNTIME_VERBOSE=1, STEAM_LINUX_RUNTIME_LOG=1, and usually PRESSURE_VESSEL_SHELL=instead.

Current status

• native Linux games can be launched (Floating Point works)
• Proton games can be launched and basically work (the Windows version of Life Is Strange works!)
• The Flatpak libshared-library-guard.so doesn't work because it's found via /app/links/$LIB, which we correctly translate to /run/parent/app/links/$LIB, but then /run/parent/app/links/lib contains absolute symlinks to /app/lib and /app/lib32. We should be able to fix this in Flathub's Steam app by changing them to be relative symlinks.

Commits

• pressure-vessel: Add experimental code path for Flatpak sub-sandboxing

  This is experimental and subject to change. It requires branches of Flatpak that have not yet been reviewed or merged, so it's guarded by (deliberately undocumented) environment variables by default. Only enable this if you are a pressure-vessel developer and know precisely what you're doing.

  This feature also requires a non-setuid bwrap executable, and a kernel that allows the non-setuid bwrap to create new user namespaces. Fedora, Ubuntu, Debian >= 11, and Arch Linux's default kernel are examples of systems that should be OK; Debian <= 10, SteamOS 2, and Arch Linux's linux-hardened are not.

  I'm landing this despite its experimental status because leaving it in a branch means we have to rebase it all the time, which just slows us down.

• runtime: Communicate whether we're going to run in a Flatpak subsandbox

• runtime: Assume /app will be visible in Flatpak subsandbox

  My Flatpak branch puts it at /run/parent/app, alongside /run/parent/usr.

• runtime: Check consistency of arguments for Flatpak subsandbox

  Flatpak subsandboxes don't have sufficiently powerful control over the container to use bubblewrap or FlatpakExports directly.