Spawning subprocesses is finicky, and the correct way to do it depends
on the current process state which we have no control of. Signal masks,
handlers, limits, scheduling and open file descriptors are a few
examples of things that inadvertently get inherited and cause issues for
either the parent or the child.
We introduced a temporary workaround against common issues by clearing
signal masks and signal handlers known to cause issues for Xwayland, but
this was only a bandaid.
Introduce xwayland_spawn_func_t, which allows the compositor to specify
an implementation of a process spawner that will be used to launch
Xwayland whenever needed. This spawner can then do any cleanup and
accounting as the compositor sees fit.
The spawner takes 4 arguments: The path to Xwayland, the arguments we
have constructed for Xwayland, the environment variables that must be
set for Xwayland, and the file descriptors that must have CLOEXEC
cleared after fork but before exec to be correctly inherited by
Xwayland.
A default implementation is provided both for convenience and as a
sample for implementers to look at.
This can be used to know when wlr_xwayland_server decides to start
a new Xwayland process. At that point the wl_client has already
been created but the Xwayland process hasn't been started yet.
