daemon: Use $XDG_RUNTIME_DIR to create keyring socket directory

We create a predictable location under $XDG_RUNTIME_DIR. GNOME does
not support multiple GUI sessions per user, so using a predictable
directory works well for us.

If someone somewhere still wants an alternate location use the
--control-directory argument.

https://bugzilla.gnome.org/show_bug.cgi?id=725801
daemon: Stop exporting the $GNOME_KEYRING_CONTROL env variable

In cases where we're using $XDG_RUNTIME_DIR to create a predictable
control socket directory, stop setting the $GNOME_KEYRING_CONTROL
environment variable.

Note that we don't use the $XDG_RUNTIME_DIR fallback. This is because
two of our clients don't link in GLib, both the pam and pkcs11
modules. Getting involved in the whole tree of fallback possibilities
for how to resolve $XDG_RUNTIME_DIR is not something I'm interested
in duplicating.

So instead what we do is if $XDG_RUNTIME_DIR is not set, we fall back
to using the old $GNOME_KEYRING_CONTROL environment variable.

We use the GLib logic when looking for XDG_RUNTIME_DIR. The variable
is considered present even when empty.

https://bugzilla.gnome.org/show_bug.cgi?id=725801
daemon: Stop exposing a GNOME_KEYRING_PID variable

We exit with the DBus session bus. Remove this clutter from the
environment.  PAM module no longer cares about the lifetime of
the deamon, except in one case: where it started the daemon in
order to change a password and the auto_start argument wasn't set.

https://bugzilla.gnome.org/show_bug.cgi?id=725801
daemon: Provide caller syncronization for quitting the daemon

Quit control messages are a bit strange because the daemon will quit
shortly afterwards.  There are three syncronization issues here.

1. We need the response to be written right away, because if
   we wait for the main loop it might not be written.
2. Callers may want to wait for the daemon to exit, so keep the
   socket open until we do.
3. Prevent additional connections on the control socket.
pam: Export a pam_sm_close_session() function entry point

Some PAM callers want this even though we don't do anything
interesting in here.

https://bugzilla.gnome.org/show_bug.cgi?id=726245
pam: Allow unlock_keyring() to be called with a NULL password

This happens when doing auto-login. The various side effects
of unlock_keyring (including setting *need_daemon) are valuable
even in the cases where password is NULL.

Add a test that checks that the daemon starts as expected when
the user did not authenticate.

http://bugzilla.gnome.org/show_bug.cgi?id=726245
pam: Pass XDG_RUNTIME_DIR to new process

If XDG_RUNTIME_DIR is not in the PAM envlist, but *is* in the
process environment, then steal it from there similar to how
we handle DISPLAY.

https://bugzilla.gnome.org/show_bug.cgi?id=726196
pam: Fix issue with changed password not unlocking keyring

If a user (needs to) change their password while authenticating (via
GDM for example), and pam_gnome_keyring is configured to start the
daemon from the session PAM stage, then we were failing to pass the
changed password to our session handler.

Fix this issue so that this workflow works.

https://bugzilla.gnome.org/show_bug.cgi?id=726196
Release version 3.11.92
Makefile.am: Fixes for building with/without optional components

Make build with --disable-pam work again. And enforce that we have
all the optional components when doing a 'make distcheck'
gkm: A testing reliability fix
build: Use /usr/bin/env to find python

https://bugzilla.gnome.org/show_bug.cgi?id=726909
Release version 3.12.0