These will always be byte streams at heart, so let's try to keep them
with a proper type. Should make it clearer how they will be used.

It is much more natural than custom methods for this very common
operation.

It doesn't use any exceptions, so stop including the header for it.

Let's use a more common type instead of something homegrown. Should be
more familiar to new developers.

This mimics how some system functions (like inet_ntop()) work, and
avoids complexity around ownership of the returned string buffer.

The downside is that the string must be consumed directly as it will be
overwritten on the next call, but that is not an issue with the current
usage.

Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.

Avoid duplication, and add logging for some more error conditions so
it's possible to see in the logs why a resize has failed or produced
unexpected results.

The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.

This fixes regression introduced by the extended clipboard extension.
Previously it was possible for the server to hold on to the CLIPBOARD
selection even if another application took ownership of PRIMARY. This is
important to handle the common use case of selecting something in order
to paste over it.

The new request based model doesn't readily support this as we assume
the client has lost its data once we push the new PRIMARY selection to
it. So to handle this we have the maintain a cache of the client's data,
and make sure to fill that cache before we do anything that might cause
the client to lose the data.

This change adds support for the VMware Mouse Position
pseudo-encoding[1], which is used to notify VNC clients when X11 clients
call `XWarpPointer()`[2]. This function is called by SDL (and other
similar libraries)  when they detect that the server does not support
native relative motion, like some RFB clients.

With this, RFB clients can choose to adjust the local cursor position
under certain circumstances to match what the server has set. For
instance, if pointer lock has been enabled on the client's machine and
the cursor is not being drawn locally, the local position of the cursor
is irrelevant, so the RFB client can use what the server sends as the
canonical absolute position of the cursor. This ultimately enables the
possibility of games (especially FPS games) to behave how users expect
(if the clients implement the corresponding change).

Part of: #619

1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding
2: https://tronche.com/gui/x/xlib/input/XWarpPointer.html
3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804

So the current clipboard state is properly reflected in the desktop
session.

It should be using the safe wrappers for everything so make sure it
cannot bypass those and call the SConnection methods directly.

We incorrectly called the underlying functions instead of the safe
wrappers for the new clipboard functions. This had the effect of a)
crashing the entire server if one of these functions failed, and b) not
respecting the settings disabling the clipboard.

Since 8e09912 this wasn't triggered properly as we checked if all
clients were gone before we actually removed the last client from our
list.

We'll just crash later if we try to use such a large screen, so reject
the request from the client instead and keep the server running.

These are not universal in the protocol so having functions for them
only obfuscates things.

The socket is closed at this point so we have to rely on a cached
value for the logging.

We need to examine the incoming PixelBuffer, not the previous one
(which might not even be valid).

Change the internal clipboard API to use a request based model in
order to be prepared for more advanced clipboard transfers.

We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.

This is required by the protocol so we should make sure it is
enforced. We are tolerant of clients that violate this though and
convert incoming clipboard data.

Add more checks and fix some callers to make sure that the server
core always has a valid screen layout configured.

It doesn't belong on each socket server object as timers are global.
Force implementations to call the Timer system directly instead,
avoiding any middle men.

Get this timeout in to the timer system as well to make things
simpler and more robust.

Do a proper cleanup when one of the termination timeouts trigger
rather than just exiting on the spot. This makes sure we don't leave
stray stuff around, e.g. unix socket files.

This makes them more consistent with everything else, which makes
things clearer and also allows them to handle some corner cases
(e.g. only firing once).

It is static and only used from a single place, so let's inline it.

It is functionality specific to WinVNC, so move the code there
to make things more clear.

Removed the last parts of VNCSConnectionST's back door in to
VNCServerST and let the parent class fully handle coordination of
clients, and access to the desktop.

This makes it generally useful and other code doesn't have to
know of the specific sub-class.

More encapsulation of functions that require coordinate between
clients.

There is some client coordination needed which is better encapsulated
inside VNCServerST. This also helps hiding the desktop from the
individual clients.

Make things simpler by making this a part of the SDesktop interface
that always needs to be implemented.

The system to avoid processing changes for a stopped desktop was a
bit overly aggressive and resulted in those changes getting stuck even
when the desktop started again (yet another change was needed to get
things rolling again).

Make sure we flush out anything pending once the desktop is back up and
running. We don't use the frame timer here as we no longer know how
old these changes are, so we're not really rate limiting any application.

There might be parts of the screen that haven't changed and can
therefore be refreshed. Figure which parts these are and send just
those.

We don't want to waste bandwidth on the lossless refresh if we might
need that bandwidth for a normal update. Try to estimate how much
data we can safely send without interfering.

No need to run all the update machinery when there is no client
connected.

This commit also cleans up the stop handling a bit by moving it to
its own method.

Originally calling VNCServertST::setPixelBuffer(PixelBuffer* pb_) with pb_=0 would do nothing.
With this change pb will be set to 0 and deferred update timer will be stopped.

There is a problematic corner case where an application is updating
at exactly the same rate that we're sending update. In that case we
may miss updates regularly, getting a very uneven final frame rate.
Avoid this by introducing a slight offset when we start updating.

The buffer is considered changed right away, so we might not get any
add_changed() calls to trigger a start of the timer.

Based on QEMU's behaviour.

This redesigns the old "deferred updates" mechanism in to a frame
clock that governs how often updates are sent out. The goal is still
the same, to aggregate updates and avoid pointless updates, all in
the name of efficiency. This model should however be more robust
against delays that sometimes causes us to miss the desired rate.

This will allow us to use better formats that preserve the entire
alpha channel.

What to do when a socket is writeable should be handled in the
RFB core code as there may be other events we want to fire off
when this happens.