Passing through signals when run with --appimage-extract-and-run

In the apprun,
when an appimage is called normally, execv is called in the parent branch of the fork, so the final process will get signals passed through to it.

However, when --appimage-extract-and-run is used, execv is call in the child branch of the fork. This means that signals sent to the process started by the user (i.e. the .AppImage itself) evaporate into thin air.

My preference would be that both modes of operation act the same way, and the process started by the user is the same process they send signals to.

The reason why I would want this is a bit more convoluted: I have an AppImage running inside a docker container. The base image for the container doesn't have FUSE available, so I run the appimage using --appimage-extract-and-run. In docker containers, PID 0 is always the actual program you want to run in the container - in my case, the appimage. When you stop a container, it can be configured so that the container will send a particular signal to PID 0 to trigger a cleanup. That signal (SIGINT or SIGQUIT in my case) isn't getting through, because it is stopping at the AppImage process, and not being passed on to the child. Eventually docker times out the stop command and sends SIGKILL which causes everything to exit hard, and the AppImage doesn't get to clean up it's temp directory.

Possible workarounds:
- I can work around this by not using an appimage at all, but then I have to solve a cross distribution library issue.
- I could change the build system version of linux to be a closer match to the docker container, or
- I could make a script to help the user figure out the correct process to shutdown instead of using docker stop.

It would be nice, however, if appimages always acted the same with with respect to signals being passed through to the actual program, whether or not they are runing extracted or with fuse.