util: do not overwrite G_MESSAGES_DEBUG=all

glib log handler only check for a single 'all' value, mixing it with
other domains name will disable 'all' messages.
util: document spice_uuid_to_string
Fix spice-common submodule, my bad
Add ability to get SpiceDisplay resolution

Add spice_display_get_monitor_config() to get the current configuration of the
display.
SpiceDisplay: validate 'self' argument for public API

Add defensive g_return[_val]_if_fail(SPICE_IS_DISPLAY()) to all public API
widget: add since tag for spice_display_get_monitor_config()
display: blank surface on creation

In theory, zero-ing the surface shouldn't be necessary, as only
invalidated/painted region should be shown. However, this results in
less artifacts on resolution changes (probably some regions are painted,
but with masks, blend, copy etc), in particular on console after VM
reboot.
Revert "Add ability to get SpiceDisplay resolution"

This reverts commit a285e0187d15ad650f6524f3811072fa55b20617.

This API was not actually needed for what I intended to use it for.  So revert
for now.  We can always add it back if necessary in the future.

Conflicts:
	gtk/spice-widget.c
Make sure property notifications are done in the main context

Modify g_object_notify_main_conetxt() to work whether it's called from the main
context or a coroutine context.  Change object notify calls in SpiceSession to
use g_object_notify_main_context() instead of g_object_notify().
Guarantee that 'uuid' property is notified after connection

This creates a synchronization point and allows API users to rely on the fact
that they'll always get a UUID notification before all of the channels are
created.
coroutine: add some preconditions
coroutine: fix current coroutine

When leaving a coroutine, it swaps back to where it came from, not to
the leader/main coroutine.
Fix crash on remote-viewer startup with gthread coroutine

g_object_notify_main_context() was recently changed to automatically
detect whether we are running in the main context or not, and SpiceSession
is now using g_object_notify_main_context().

In order to achieve that, IN_MAIN_CONTEXT is used, but it's not safe
to be used before coroutine_init() is called. IN_MAIN_CONTEXT expands to
(coroutine_self()->caller == NULL), but coroutine_self() will be NULL when
using gthreads for the coroutine implementation until coroutine_init() has
been called.

Before coroutine_init() has been called, we'll always be running in the
main context, so we can just add a check for coroutine_self() != NULL to
IN_MAIN_CONTEXT to solve that issue.
Fix IN_MAIN_CONTEXT when using coroutine=gthread

The IN_MAIN_CONTEXT macro checks coroutine_self()->caller against NULL to
decide whether we are in the main context or not. However, this is an
implementation detail of the ucontext coroutine implementation, in the
gthread implementation, coroutine_self()->caller will be non-NULL even in
the main context.

This commit introduces a coroutine_is_main_context() method which each
coroutine backend implements. It turns out it can be implemented the same
way for each backend.
Abort if mmap of coroutine stack fails

If we fail to mmap the stack, abort the processs rather
than returning an error. This is standard practice in
glib apps, and the caller was not checking the
coroutine_init() return code leading to memory corruption.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Free coroutine stack when releasing coroutine

The coroutine_init function mmap's a stack for the
ucontext coroutine, but nothing ever munmaps it.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Check coroutine_init() return value

coroutine_init() can fail, but spice-channel.c was not checking its return
value, which could lead to some crashes if coroutine_init() failed and we
then try to use coroutine_yieldto()
Fix leak of mmapped memory when cc_init() fails
build-sys: Fix invalid 'test' syntax in configure.ac

test ... -o test ... is not a valid shell construct, change it to
test ... || test ... as this is more portable than test ... -o ...

This was causing a warning when running configure.
build-sys: Re-enable building of python bindings by default

Commit daa4ece tried to disable building of python bindings on Windows by
default, but in doing so, it also disabled building of python bindings by
default when we are building neither for Windows nor for gtk3.