Since the context has the last reference on the proxies, it has to take
care of their destruction.
So, destroy the remote-desktop- and screen-cast-proxy before setting new
values.
Also make sure that both proxies are cleared on destruction of the
context.

Since the introduction of the support of copy pasting files with FUSE,
this error message is not correct any more, as the parent directory for
gnome-remote-desktops base directory changed from the user cache
directory to the XDG runtime directory.

When updating the ping source, gnome-remote-desktop clears the previous
GSource first, if it is required.
If it is not required, then gnome-remote-desktop won't clear the
existing GSource.
This behaviour is correct. However, when it is not required to update
the ping source, gnome-remote-desktop will still attempt to create a
new GSource and replace the existing GSource with the new one.
The old GSource will then remain to exist and cannot be removed any
more, since no reference to that GSource is left.

Fix this behaviour by just returning from the function in such
situation.
Currently, gnome-remote-desktop does not run into this situation, since
it seems that all known RDP clients seem to behave well with the
SuppressOutput PDU.

When the RDP or VNC backend disable the clipboard, since the session is
about to be destroyed, then gnome-remote-desktop could still receive
SelectionOwnerChanged- and SelectionTransfer-signals.
Currently, these signals are handled unconditionally.

To ensure that this won't be the case any more, ignore these signals,
when the clipboard instance is unavailable.

Currently, when gnome-remote-desktop handles a SelectionTransfer-
signal, the mime type content is requested synchronously from the
respective backend.
Since this process is done synchronously, the main thread is blocked
and cannot handle any other events, such as input events.
With additional network latency, this becomes worse.

To allow the backend implementations to transform to an asynchronous
implementation, split up the SelectionTransfer handling.
The signal will now just emit the request on the backend and the
backend will, when it has the response ready submit the response
itself.

Both the RDP and VNC backend will currently still function as before,
as the handling is just split up.
Since the VNC backend does not support delayed rendering of clipboard
data, no further changes will happen for the VNC backend.
The RDP backend, on the other hand, will be reworked in the next commit
to handle mime type content requests asynchronously.

The previous commit split up the SelectionTransfer handling, allowing
the backends to handle mime type content requests for the client in an
asynchronous way.
In order to handle the mime type content requests asynchronously, split
up grd_clipboard_rdp_request_client_content_for_mime_type() into
multiple parts:

The first part, about retrieving the mime type content from the
FormatData cache remains.
Same with the next part, when gnome-remote-desktop fails a request,
when a new FormatList is received from the client, since mstsc will
then not submit any FormatDataResponse in that situation.

Next, implement the new part:

If a there is currently already a mime type content request pending,
just enqueue the new request.
This is done with a hash table and a queue.
The hash table tracks all serials for a request for each specific mime
type.
This allows gnome-remote-desktop to group multiple requests into one
request.
If a response for the mime type content request is received, all
serials are answered together.
The queue preserves the order of these mime type content requests, so
that all requests are handled fairly, while also tracking the
respective MimeTypeTables, which contain the foreign format ids, which
are necessary for the mime type content conversion operations.

If no mime type content request is pending, send the mime type content
request via a FormatDataRequest and save the serial.
Also create a timeout source to abort the current request in case no
FormatDataResponse is sent by the client.

After sending the mime type content request, the new
grd_clipboard_rdp_request_client_content_for_mime_type() procedure ends
here.

If the client did not send the FormatDataResponse and the timeout
source runs, abort the current mime type content request by answering
all serials for this request with a fail response.
Then send the next mime type content request, if there is one queued.

If the mime type content request is still pending, but a new FormatList
is received from the client, abort all pending and queued mime type
content requests.
This is necessary, since mstsc will not answer these requests any more,
so gnome-remote-desktop has to fake their responses.

If a FormatDataResponse is received, gnome-remote-desktop can handle
the response for the mime type request.
For this, the CLIPRDR thread queues the task via a GSource onto the
main thread and duplicates the response.
This is necessary, as the FormatDataResponse, owned by the CLIPRDR
thread, is only valid as long as the callback function runs.
If there is no current mime type content request pending, the response
is discarded.

The handling of the FormatDataResponse on the main thread uses the last
part of the old
grd_clipboard_rdp_request_client_content_for_mime_type() function.
First, the data is extracted and the flags are checked.
If the response was successful, convert the received mime type content,
if necessary.
After this, answer all serials for the given mime type.
If the response was not successful, answer all serials for the given
mime type with a fail response.
At the end of this handling, send the next mime type content request,
if there is one queued.

Indicate in the warning message, that the conversion failed for a
request from the client.

When looking up the username or password for an RDP session,
gnome-remote-desktop will parse the credentials string, returned via
libsecret.
This credentials string may exist, but it can contain garbage values,
when e.g. the user changed them to such garbage values.
In such case, the parsed username or password may be NULL, leading into
gnome-remote-desktop to crash, as the error is not set.

Fix this behaviour by always setting the GError, when the username or
password is NULL.

While commit b17d0bef fixes a crash,
when the username or password is NULL, it accidentally leaks the string
with the credentials, which is in such case not NULL.

Use the autofree- and autoptr- helpers to get rid of any leaks here.

Fixes: b17d0bef

Otherwise we might receive notifications after stopping or even
finalizing, causing crashes.

This method will be called in the next commit, when the session is
stopped to prevent calling the connected callback, when the actual
session is already stopped or destroyed.

In order to start a remote desktop session, gnome-remote-desktop calls
several dbus methods on the remote desktop- and screencast interface of
mutter.
These calls use in glib internally GTasks and will always run their
async-ready-callback, when the task is done, aborted, or cancelled.
This also applies to situations, where the session is immediately
stopped or destroyed.
In such cases, the callback should not be handled any more, as parts of
the session are already destroyed, due to the session already been
stopped, or the complete session is already destroyed.
The result is usually a crash, as gnome-remote-desktop tries to stop
the session, although it is already stopped or destroyed.

To prevent these situations, always cancel the cancellable, when
stopping the session.
When a async-ready-callback is called, don't directly derenference the
user date.
Instead, call the finish function first and check the error code.
When the cancellable was cancelled, the finish function will not return
successfully and set the error.
The error code will in such cases be G_IO_ERROR_CANCELLED.
If that is the case, just return, as the session is already stopped.