When gnome-remote-desktop is started, it attempts to initialize the RDP
and VNC backend, depending on with which backends gnome-remote-desktop
was built.
However, if all backends fail to initialize, gnome-remote-desktop will
still continue to run, despite not being usable.
This is especially problematic, as the systemd user service still runs
as if there would be no problem, making it hard to find the cause why a
connection to the server won't make it.

To get rid of this situation, also check the result of the backend
initialization.
If all backends fail, exit the daemon, as there is no reason to
continue running.

All D-Bus operations happen in the main thread, which is unlikely to
change.
So, explicitly use the global main context, as the threads default
GMainContext might not always be the global one.

While g_main_context_get_thread_default() refers in the context of the
timeout_reset_source creation to the global main context, this function
can technically also return a different main context.
The intention is, however, that the timeout_reset_source always runs on
the main thread.

Thus, change the main context, to attach the GSource to, to NULL, which
refers to the global main context.

Currently, when the PipeWire stream parameters of the monitor content
change, grd_session_rdp_resize_framebuffer() is called.
However, this call is not necessary and can be delayed right before the
next graphics update.
In addition to that, this also allows to easily run do_render() later
in a different thread, as no order of graphics output buffer resizes
and frame updates needs to be considered.

So, remove the grd_session_rdp_resize_framebuffer() API from the
session-rdp header file and make this function private.
Call this private function then at the beginning of
grd_session_rdp_take_buffer() to ensure that the graphics output buffer
is correctly resized.

The usage of a custom GMainContext for all RDPGFX specific GSources is
a required step in order to be able to run all graphics operations in a
separate thread.

In order to be able to run all graphics operations in a different
thread, add a new GSource, which runs do_render() as callback function.
This GSource will then be attached to a custom GMainContext.
In a future commit, this custom GMainContext will be the GMainContext
of the graphics thread.

In order to allow CUDA function correctly, the current CUDA context
needs to be pushed for its calling thread.
Since all graphics operations will happen in the future in a different
thread, add APIs to set these threads correctly up.

maybe_queue_close_session_idle() can be called from three different
threads:

1. The main thread (e.g. when the remote desktop session is stopped
   from the g-s system menu).
2. The socket thread (most common case) (e.g. when the user closes the
   RDP client)
3. The RDPGFX thread inside FreeRDP (e.g. when the RDP client uses the
   CapsAdvertise PDU without providing any capability sets.

To avoid race conditions, when queueing the idle source to stop the
remote desktop session, add a mutex around close_session_idle_id, when
creating the idle source.

Currently, all graphics operations happen in the main thread, which
means that remote input is delayed until the current graphics
operation, such as encoding frame content for example, is done.
On very slow servers or with the raw bitmaps path in the legacy path,
this highly reduces the input responsiveness, as the main thread can
become fully occupied.

So, run all graphics operations in a separate thread, while the main
thread takes care of pushing the input events to mutter.

Currently, when the PipeWire stream is destroyed, there could still be
a pending frame, that won't be encoded any more.
In such case, the frame data is leaked.

So, fix this by freeing the pending frame data, when the stream is
destroyed.

With the graphics pipeline, gnome-remote-desktop has a way to control
to control the encoding rate based on the speed of decoding and
displaying frames on the client side.
With the PipeWire stream running at 60 FPS also decreases the frame
latency between when the frame was rendered by mutter and when
gnome-remote-desktop can start encoding it.
A 60 FPS PipeWire stream does not mean that 60 are always reached.
The maximum FPS is determined by the minimum of the encoding rate in
gnome-remote-desktop and the frame acknowledge rate of the RDP client.

Currently, when using the raw bitmaps path, every worker thread in the
raw bitmaps path signals the GCond for the thread pool once their task
is done.
However, this is wasteful, since the only necessary signal here is the
final one, where the last tile is being encoded.

So, make the signal call conditional. For a FullHD frame this saves
about 509 unnecessary wakeups of the graphics thread.

Currently, gnome-remote-desktop always assumes that
ConvertFromUnicode() never fails.
While this is usually the case, this behaviour should not be assumed by
default, as on invalid input ConvertFromUnicode() will fail.

So, always check the return value of ConvertFromUnicode(), which
indicates whether the conversion was successful or not.

When outputting debug information about which FuseFile is opened, the
FuseFile path might already be invalid, since the FuseFile could
already be deleted due to a new clipboard selection.
While this situation is unlikely to happen, since pasting content and
copying content would have to happen at the same time, it is in theory
still possible.

So, duplicate the FuseFile path before unlocking the filesystem mutex.
This will avoid this situation.

The NVENC include is currently conditional, so put it under the
unconditional includes.

The surface context of a surface exists until the surface is deleted
and all references are cleared.

So, when looking up a the surface context to ack a frame, unref the
serial afterwards and not before, as otherwise gnome-remote-desktop
would crash since the surface context might already be deleted, due to
the already been deleted.
Currently, gnome-remote-desktop is not able to crash with its current
architecture here, since only one monitor is screencasted and the GFX
surface currently exists until the end of the remote desktop session.

Currently, when gnome-remote-desktop receives a new frame update via
PipeWire and an already pending frame exists, then this frame will be
replaced.
However, not every frame contains all data. For example frame n can
contain both actual frame data and a new mouse pointer bitmap, while
frame n + 1 might contain only actual frame data.
In that case, the mouse pointer bitmap update will be omitted.

To prevent this behaviour, take the frame data of the previous frame.

Currently, when gnome-remote-desktop receives a new frame update via
PipeWire and an already pending frame exists, then this frame will be
replaced.
However, not every frame contains all data. For example frame n can
contain both actual frame data and a new mouse pointer bitmap, while
frame n + 1 might contain only actual frame data.
In that case, the mouse pointer bitmap update will be omitted.

To prevent this behaviour, take the frame data of the previous frame.