This commit checks if plymouth is running, and if so,
turns on the smooth transition between plymouth and X.

This combined with starting the X server with -nr
will give us a nice fade transition when g-s-d starts

Port over gdmflexiserver to use native systemd calls with a fallback on
CK.

systemd 39 and newer provide a small wrapper for X which works around
the fact that XOrg upstream currently support multi-seat hotplug for
displays. Let's make use of this as a stop-gap until this feature is
added to XOrg upstream.

This code tries to be as defensive as possible and makes use of the
wrapper only if the system as actually booted with systemd, the wrapper
is available and we actually use a seat != "seat0".

When we spawn a new X server, let's pass the seat id to it via the
"-seat" parameter, which has been available since a while in upstream
Xorg.

-seat causes the X server to only make use of hardware that is assigned
to the seat specified, and leave all other hardware untouched.

logind will notify us when ever a new seat becomes available in the
system, or an existing seat is removed. We simply create a new display
for each seat showing up and remove a display when a seat goes away.

This optionally replaces the current CK session registration logic with
support for passing seat information to pam_systemd (and hence rely on
pam_systemd's session registration).

With this patch applied we can register sessions in systemd and in CK
with the same binary.

Pass seat id from product and simple slave to the direct sessions
created by it (along with the other display meta data we pass already).

Pass seat id from session to worker (via D-Bus) along with the other
display meta data.

We need the seat information for the PAM conversation (later patch)
hence we need to pass it from the slaves down to the workers.

(Note that the seat ID has always been passed from the display to the
slave, we just need to pass it on the worker now, so that the chain is
complete: display → slave → session → worker)

Nothing was using register-ck-session and it has no effect, hence let's
get rid of this dead code.

There's no situation where it's the right thing to do.
The children of the daemon are responsible for themselves.
If they don't go away when asked we shouldn't second guess
them, we just need to ignore them.

This means we may end up with zombie children if those children
have bugs, but it's better than prematurely killing them if they're
slow.

It's spelled XDMCP not XMDCP

https://bugzilla.gnome.org/show_bug.cgi?id=663338

They're warnings the user won't see without snooping.
They are hardly intelligible as it is and shouldn't
be translated, so they're easy to google.

If the slave tells us to go away, we should go away,
not wait a PAM module decides to let us get back to the
main loop.

Sometimes PAM modules are finicky and don't die when you tell them to.
Instead they fail some seconds later.

If a user successfully logs in with one stack and another stack is
being troublesome, then we'll get notified about it finishing up
after the user is already logged in.

When that happens, we erroneously assume the stack finishing is the
stack the user's session is running on and then proceed to log the
user out.

This commit makes us be a little more careful about our bookkeeping
so we can ignore failures from slow PAM modules.