Try to transform LD_PRELOAD entries from caller namespace into container namespace

The following discussion from !146 (merged) should be addressed:

• @smcv started a discussion:

  I think we ideally need to be handling LD_PRELOAD more cleverly.

  For the most general setup, consider a user running Steam with an LD_PRELOAD already in the environment, in "session mode":

  LD_PRELOAD=myhack.so steam
   \- _v2-entry-point
       \- _start-container-in-background
            \- (enter container)
                 \- adverb
                      \- launcher
                          \- setup command <- (1)
                          \- setup command <- (2)
                          \- main game <- (3)
            \- launch -> (1)
   \- _v2-entry-point
       \- launch -> (2)
   \- LD_PRELOAD=gameoverlayrenderer.so:myhack.so _v2-entry-point
       \- launch -> (3)

  ((1), (2) and (3) are IPC: imagine pairs of blue and orange portals :-)

  Each LD_PRELOAD module could be from:

  • the Steam client itself, which is always exposed (the gameoverlayrenderer falls into this category)
  • the user's home directory
  • the host OS (/usr and friends)
  • some random other location (/opt, /srv, whatever)

  At the point where we enter the container, we know about myhack.so, only. We can adjust its path in wrap.c to be something that can validly appear inside the container (this is what adjusted_ld_preload is about):

  • Steam client itself: no action needed
  • user's home directory: don't adjust, but do make sure the path is exposed as if via --filesystem
    • if we're in Flatpak, then we would ideally also put this through pv_current_namespace_path_to_host_path(), although we don't do this yet
  • host OS: adjust /usr to /run/host/usr, etc.
  • some random other location: same as home directory

  However, to run the main game, Steam adds gameoverlayrenderer.so to the environment. It could validly add other LD_PRELOAD modules if it wanted to (although currently it does not). Because the container is already up and running, we cannot expose additional paths. Ideally we would do something like this:

  • Steam client itself: no action needed
  • user's home directory: don't adjust; we have to just hope the path is already exposed, because if it isn't, then we're too late to fix that
    • if we're in Flatpak, then we would ideally also put this through pv_current_namespace_path_to_host_path(), although again we don't do this yet
  • host OS: adjust /usr to /run/host/usr, etc.
  • some random other location: same as home directory

  I don't know how best to solve this.