Using g_main_loop_run here appears to be inherently necessary for the
g_file_mount_enclosing_volume/g_file_mount_enclosing_volume_finish protocol, but
has at least two problems:  For one, it temporarily drops the SolarMutex (if it
was held by the current thread), causing the usual integrity issues caused by an
inner stack frame temporarily releasing the SolarMutex that is held by some
unsuspecting caller.  This is an inherent problem of our broken SolarMutex
design, and this change can't do much about it.

But for another, at least with GTK-based VCL backends, it also means that the
current thread can start to execute VCL events at "unexpected" times from within
this g_main_loop_run (e.g., paint events, as in the backtraces linked from
tdf#124962).  While handling of VCL events is necessary when a callback to
ooo_mount_operation_ask_password happens and it actually pops up a dialog
prompting the user for credentials, such handling of VCL events is completely
unwanted when no such dialog is popped up (e.g., when the given server is
unreachable anyway, as is the case in tdf#124962).

So, to shrink the problematic window of time in which VCL events may get handled
from within the gio MountOperation, use a dedicated GMainContext for the gio
GMainLoop (so that it only handles events related to the mount operation), and
only temporarily put back in place the original GMainContext during
ooo_mount_operation_ask_password (so that VCL events will get handled as
necessary when a dialog is actually popped up).

Change-Id: Ie410f23778045b1adf98579bb34ce38d0f8f3320
Reviewed-on: https://gerrit.libreoffice.org/72026
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>