The RTT pause source callback runs in the graphics thread, which is not
the main thread.
To ensure no race conditions happen, create this source, while the GFX
mutex is locked.

Currently, gnome-remote-desktop does not create the initial GSource to
emit pings, unless ping interval changes to low due to inactivity on
the screen.
As a result, stutters can appear.

To fix this issue, introduce a new ping internal with the name "NONE".
This new interval represents the absence of the ping source.
When the client emits the SuppressOutput PDU, where
gnome-remote-desktop stops emitting pings, also reset the ping
interval.

The same assertion exists for ensure_rtt_consumer(), so add it for
consistency.

The if condition is here superfluous, as the ping info always exists at
this point here.
This is ensured by the previous condition, that uses
g_hash_table_contains().

RDP clients can tell the user about the quality of the network
connection.
This is done with the help of the network characteristics results, that
are sent by the server.
The RDP protocol currently allows these characteristics to be sent in
the following combinations:

1. Base RTT, and average RTT value
2. Bandwidth speed, and average RTT value
3. Base RTT, bandwidth speed, and average RTT value

FreeRDP currently implements combination 1 and 3.
So, to be able to send these characteristics, also determine the base
round trip time value.
Then send the Network Characteristics Result PDU, when receiving RTT
responses.
Since, for the server side only RTT values with ping intervals way
lower than one second are useful, Network Characteristics Result PDUs
should not be sent upon retrieval of any RTT response, as otherwise the
RDP client might update the network indicator very rapidly.
Usually, ping values in applications are updated every second, so add
additional handling to ensure the same behaviour is achieved.

mstsc has a network indicator icon, which is only shown, when the
server side also sends Network Characteristics Result PDUs containing a
bandwidth measurement result.
Currently, gnome-remote-desktop does not measure the bandwidth, so add
additional APIs to be able to perform these measurements.
Measuring the bandwidth is useful for screen updates.
With the graphics pipeline, progressive rendering is possible, which is
helpful for low bandwidth scenarios.
Currently, it is not yet implemented, but will hopefully be in the
future.
Since sending screen updates in the graphics pipeline is done in an
async way, add an additional API to be able to queue a bandwidth
measure stop.
To be able to be notified of such queued bandwidth measure stop, add an
API to retrieve the associated WinPR event handle.

The socket thread, where channel messages, including graphics updates
via the graphics pipeline,  are sent to the client, needs to take care
of sending queued Bandwidth Measure Stop PDUs.
To do this, use the previously implemented APIs to retrieve the event
handle for queued updated and the API to actually send the Bandwidth
Measure Stop PDU.

With the APIs now being available, measure now the bandwidth, when
sending frame updates.
Since gnome-remote-desktop can only account for the network
characteristics when using the graphics pipeline, only measure the
bandwidth there.

(cherry picked from commit 97efa217)

Upstream version 42.2