server: Pull out common X server args
server: Force server regeneration off

Server regeneration causes Xorg to re-emit the SIGUSR1 signal, which
*really* confuses our state machine. Since we also want to control
the server lifetime fairly closely, it doesn't really make sense for
it to ever trigger, so force it off.
Move gdm_slave_run_script to common code

We're going to move the code that runs Init to gdm-server.c and
the code that runs PostLogin / PreSession to gdm-session-worker.c
server: Move Init script processing here

We still need to have it in the XDMCP chooser slave, since we need to
initialize the X server, even if we didn't start it ourselves.
session-worker: Move PostLogin / PreSession / PostSession here

Pushing these up to the session worker dramatically simplifies the
interface for the slave, which will allow us to kill the slaves as
separate binaries.

Ideally, in the long-term, these scripts should go away.
Integrate the slaves into the main daemon process

For no particular reason, the slave has been kept as a separate process.
Integrate this into the main display process by simply making the display
keep a handle to a GdmSlave object. To keep the cleanup simple, we won't
remove the GdmSlave subtypes yet. A future cleanup should merge the slave
functionality into GdmDisplay and its subtypes.
display: Enforce a few invariants

The GdmDisplay should only be cleaned up if it's finished
or failed.
display: Remove some unnecessary parts from dispose

These can't possibly be active and armed if we're disposing.
display: Clean up old signal handlers

The signal handlers here are intended to be used if the slave itself
tries to stop, for instance if the server or greeter die, and will
try to finish the display on its own.

Letting the signal handler run again will finish the display *again*
after an idle, meaning we have this path:

  gdm_display_finish
  gdm_display_unmanage
  on_server_stopped
  queue_finish

  ... idle ...

  gdm_display_finish
  gdm_display_unmanage
  on_server_stopped
  queue_finish

  ...

This might have been an infinite loop, except for the fact that GDM
smartly has code to detect the failure state where the X server
starts up and stops sufficiently quickly, and in that case transitions
the display to the FAILED state, which causes GdmDisplayStore to
unref the last ref on the GdmDisplay.

Since the finish is still queued, finish_idle runs, and very quickly
discovers that our object is no longer a GdmDisplay, so this very
quickly manifests into a:

  gdm_display_finish: assertion 'GDM_IS_DISPLAY (display)' failed

error. Not before poking a hole and corrupting some memory trying
to clear the finish_idle_id, however.
manager: Make migrated a special case when starting the session

We have three cases for starting a session:

 1) We migrate to an existing session. Simply tear down state
 and switch.

 2) We're starting a new session, and it's a traditional Xorg
 server. Tear down the greeter, and keep the same X server and
 GdmDisplay, and start a full user session.

 3) We're starting a new session, but it's a display server. Keep the
 greeter around and give it a new seed session, and start a full user
 session.

The last two cases are really the two sides of the same coin, while the
migrated case is really a fast-path special case that doesn't involve
launching a user session in any case, so use a "goto out;" as a fast
return rather than an if/else.
manager: Rename the "user session" or "session" to the "seed session"

A greeter environment always has two sessions: the greeter session, and
the "user session".

The "user session" tracks the login PAM conversation. PAM conversations
need to be created without any user, so the name "user session" is a bit
of a misnomer.

The "user session" is created when the greeter is created, and exists
when we're sitting at the username prompt. When the username is entered,
we then start a session worker. When the verification conversation is
finished, we then log the user in. The same exact GdmSession follows
into the user session.

Traditionally, the user session is started on the same X server as the
greeter, so the GdmDisplay and GdmSlave all go with it. With the new
display server management, we need to make the GdmSession follow into
the user session created for the login, and then start a *new* user
session for the next user that logs in on the same greeter.

The name "seed session" tries to capture this. The GdmSession starts out
as a little seed, and with a username and password, will one day blossom
into a beautiful little user session which will one day live on its own,
free from the greeter that gave it life and nourished it.

It's the circle of life, and it moves us all.
manager: Don't reuse the same X server when we have a display server

Rather than morphing our own X server into the user's session
the login screen on the same VT, and start the user session. GNOME will
activate its session when ready.
session-worker: Allocate a new VT for sessions with their own display server

Ideally, we would simply set XDG_VTNR=auto, but that doesn't work yet,
so query the first open VT, and set XDG_VTNR to it when we have a
display server.
Add wayland-sessions

Add the wayland-sessions directory, as shipped by gdm.
session: Add a simple and naive way to detect Wayland sessions

Simply look for "wayland-sessions" as a path element.
session: Wayland sessions bypass Xsession
session: Wayland sessions have their own display server