build-sys: fix --with-sasl

The default configure sasl auto setting will error out if SASL is
missing. Instead, silentely skip sasl configure if detected missing.
build-sys: add --with-audio=auto

Defaults to GStreamer on Windows, and PulseAudio otherwise atm.
Update spice-common
build-sys: do not compile python binding with windows by default
win32: fix alt-tab grab regression

Since 5f67178c, alt-tab is no longer grabbed by the client. The keyboard
hook still needs to handle WM_SYSKEY{DOWN,UP} messages.

https://bugzilla.redhat.com/show_bug.cgi?id=873341
spice-channel: Fix usbredir being broken since commit 159c6ebf

The usbredir channel uses spice_msg_in_raw to get its data, which uses
in->dpos to determine the msg size and that was no longer being set for
non sub-messages.

https://bugs.freedesktop.org/show_bug.cgi?id=69935

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
mono cursor: increase contrast, better looking putty cursor (rhbz 998529)

Signed-off-by: Alon Levy <alevy@redhat.com>
display: fix palette regression

palette_get() used to return a ref, and palette_release() used to
release that ref.

Since ed877341, the palette is no longer refcount'ed, since its usage is
exclusively local in common/canvas code.

palette_release() shouldn't remove the palette from the cache.

https://bugzilla.redhat.com/show_bug.cgi?id=1011936
display: cache id is uint64_t
main: fix notify of agent disconnection

spice_main_channel_reset_agent() reset connected state, and prevent
notify of property change.

This is a minor regression introduced in c3adb24425.
gtk-session: fix clipboard_agent_connected

Use swapped connection to pass data as first argument to signal handler.
gtk-session: avoid mainloop recursion in clipboard_get

clipboard_get() exits when the clipboard data is received, or when the
agent connection state change. However, if the agent is already
disconnected, neither of those 2 conditions can be reached.

Check if the agent is connected before running loop, exit early if not.
Use latest warnings.m4 from gnulib

The one we were using does not work properly with clang, causing
the build process to try to use -f/-W options that are not
supported by clang.
Reenable call to switch_protocol() on protocol version mismatches

This partially reverts b19acbc. This commit broke the fallback
to the old protocol as it added a check for c->peer_msg != NULL
before calling switch_protocol(), but mismatch between local
and remote protocol versions is detected before c->peer_msg is
allocated, so:
    if (c->peer_msg != NULL && c->link_hdr.major_version != 1) {
         SPICE_DEBUG("%s: error, switching to protocol 1 (spice 0.4)",
c->name);
         spice_channel_switch_protocol(channel, 1);
         return TRUE;
    }
will never get triggered when c->peer_hdr.major_version !=
c->link_hdr.major_version

The crash described in b19acbc occurred when calling
spice_channel_recv_link_msg() in spice_channel_coroutine()
after a call to spice_channel_recv_link_hdr() failed and did
not set c->peer_msg.

This commit removes the c>peer_msg check done before calling
spice_channel_switch_protocol() so that it gets called when needed,
but makes sure that we return FALSE to indicate that an error happened
and that we need to reconnect. This way we won't try to call
spice_channel_recv_link_msg() when c->peer_msg is NULL.
Fix switch to old SPICE protocol

After the previous commit, spice_channel_switch_protocol() is now
called when needed, but it's not doing anything. What happens is
that spice_channel_switch_protocol() triggers a channel disconnection
and then it queues an idle to reconnect (after having changed the
protocol version to be used).

When spice_channel_recv_link_hdr() returns, we need to jump out of
the coroutine to let the idle trigger and the new channel coroutine
be started. But jumping out of the coroutine will call channel_disconnect()
which calls channel_reset() which disables the idle switch_protocol()
just queued. This causes the connection attempt to be apparently
stuck with nothing happening.

Falling back to the older SPICE protocol is not the only situation
when we need to drop the current connection attempt and reconnect,
we also need to do that when the remote server returns
SPICE_LINK_ERR_NEED_SECURED to let the client know it needs to use
a secure port for this channel. This is handled by the 'switch_tls'
variable set in spice_channel_recv_link_msg and handled in
spice_channel_coroutine().

'switch_tls' does the same thing as spice_channel_switch_protocol(),
except that it calls spice_channel_connect() after channel_disconnect()
has been called, which means the idle queued by channel_connect()
won't get cleared.

This all that commit does, remove the spice_channel_switch_protocol()
method and use the same codepath as 'switch_tls' to handle the
reconnection.
Fix --spice-debug

If spice_util_set_debug() gets called before spice_util_get_debug(),
then the value set using spice_util_set_debug() will be overridden
by the result of g_getenv("SPICE_DEBUG") != NULL the first time
spice_util_get_debug() is called.

This causes remote-viewer --spice-debug to not enable debug as
advertised if SPICE_DEBUG is not set.

An alternate fix would have been to set debug_once.status to
G_ONCE_STATUS_READY but then we would lose the thread-safety
guarantees GOnce gives us.
Display g_debug messages when SPICE_DEBUG is set

When SPICE_DEBUG is set but --spice-debug is not used, we fail
to set G_MESSAGES_DEBUG to the log domain used by spice-gtk, which
causes debug messages not to be printed as one would expect.
sasl: Fix crash when ending a SASL session

When exiting remote-viewer after authenticating through SASL, I got
this crash:

 #0  0x0000000100a51870 in ?? ()
 #1  0x000000314d20c53e in _sasl_log (conn=<optimized out>, level=5, fmt=0x7fffe49893e8 "DIGEST-MD5 client mech dispose")
     at common.c:1985
 #2  0x00007fffe4982d88 in digestmd5_client_mech_dispose (conn_context=0xaf1900, utils=0xaefd10) at digestmd5.c:4580
 #3  0x000000314d208654 in client_dispose (pconn=0xaf0710) at client.c:332
 #4  0x000000314d20b76b in sasl_dispose (pconn=0xa51898) at common.c:851
 #5  0x00007ffff7602dc7 in channel_reset (channel=0xa52250, migrating=0) at spice-channel.c:2493
 #6  0x00007ffff760f7b7 in spice_inputs_channel_reset (channel=0xa52250, migrating=0) at channel-inputs.c:615
 #7  0x00007ffff76030ac in spice_channel_reset (channel=0xa52250, migrating=0) at spice-channel.c:2551
 #8  0x00007ffff76031e0 in channel_disconnect (channel=0xa52250) at spice-channel.c:2570
 #9  0x00007ffff760283d in spice_channel_coroutine (data=0xa52250) at spice-channel.c:2368
 #10 0x00007ffff763d14b in coroutine_trampoline (cc=0xa51900) at coroutine_ucontext.c:58
 #11 0x00007ffff763ce30 in continuation_trampoline (i0=10819840, i1=0) at continuation.c:49
 #12 0x00000031342479c0 in ?? () from /lib64/libc.so.6
 #13 0x0000000000a51cc8 in ?? ()
 #14 0x0000000000000000 in ?? ()

It turns out that the sasl_callback_t data passed when calling
sasl_client_new() must be valid until sasl_dispose() is called. I could not
find mentions of this in the official documentation but
https://mail-archives.apache.org/mod_mbox/subversion-dev/201109.mbox/%3C20110908072256.GN25324@ted.stsp.name%3E
describes what happens.
Making the sasl_callback_t structure static should be enough to guarantee
that the data will stay around long enough.
main: add missing vdagent caps name

This is useful in debug messages atm.
cursor-channel.c: add cursor print function for debugging only (ifdefed)