We can no longer assume maskRect() will tolerate uncropped data.

We need to restore the previous, more complex API in order to
easily handle masks now that we no longer accept out-of-bounds
operations.

There has been multiple attempts at tricking decoders to exceed
the boundaries of the active pixel buffer. Add extra checks to
prevent such invalid access.

It can be triggered by RRE message with subrectangle out of framebuffer
boundaries. It may prevent the same kind of issue caused by evil message
from another encoding too.

The hextileDecodexx functions do not properly check for out-of-bounds writes,
which allows a malicious server to overwrite parts of the stack.

Any caller using add or remove should also be able to list the
sockets.

Some of these were excessively large because of redundant factors
in the size calculation.

These are reference counted so it is important to retain symmetry
between the calls. Failure to do so will result in bad memory access
and crashes.

168b92c broke the handling that assumes display 100 and above are
actually a port number.

Use the platform independent primitives instead.

It now does more validation, and handles unescaped IPv6 addresses
better.

We've stolen the Xregion code from libX11, so let's keep the same
header naming so that it is easier to keep things in sync.

There might be stuff lingering in the buffer simply because flush()
hasn't been called in a while, rather than because the transport is
congested.

We now get notifications when the output buffer empties, and we
already caught incoming RTT pongs, meaning we can now react at the
proper time to retry a congested update rather than use a timer.

This makes sure we keep the socket busy even if one rect takes some
time to encode.

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.

They just end up burning CPU fighting each other without much
improvement to the decoding time beyond four threads.

We can start creating more decoding threads now that we handle
rect ordering properly. No point in creating more threads than
there are CPUs though.

The cost is some more load on malloc(), but it should be small
compared to the gains of spreading the CPU heavy JPEG decoding
over multiple CPUs.

Some encodings only cause dependencies between rects some of the
time. Make sure we can allow parallel decoding of those rect that
aren't dependent on each other.

Some encodings must be handled in the order they are received.
Make sure we respect this in the decode manager.

Allows us to add attributes later that affect of the decoder
manager deals with the decoders.

This implements the basic infrastructure for multi-threaded
decoding of rects. However there is just one thread reading data
and one thread decoding it. More logic is needed to safely decode
multiple rects at the same time.

We need more callbacks for correct operation of multi-threaded
rect decoding.

It previously only did a reset of the ZlibInStream object, not the
underlying zlib stream. It also had the side effect of flushing
the underlying stream and disassociating from it.

Clear things up by changing the naming, and introducing a proper
reset function (which is needed by the Tight decoder).

We need to split these steps up in preparation for multi-core
support. Reading needs to be done in a serial manner, whilst
decoding can be done in parallel.

This also involved a rather large cleanup of the Tight decoder.

Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.

mingw has a perfectly functional gettimeofday() so use that instead
of having multiple copies of our own version.

libjpeg doesn't update the buffer state before calling the
empty_output_buffer() callback so we need to flush everything,
not just the apparent size.

Makes it easier to troubleshoot keyboard issues by printing exactly
what key events the server is getting from the client.