Fix warnings emitted by Clang:

/home/shade/dev/tigervnc/common/rdr/FdInStream.h:30:9: error: 'rdr::FdInStreamBlockCallback' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
  class FdInStreamBlockCallback {
        ^
In file included from /home/shade/dev/tigervnc/common/network/TcpSocket.cxx:44:
In file included from /home/shade/dev/tigervnc/common/network/TcpSocket.h:31:
/home/shade/dev/tigervnc/common/network/Socket.h:82:9: error: 'network::ConnectionFilter' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
  class ConnectionFilter {
        ^
..etc

Fix the following warnings emitted by Clang:

/home/shade/dev/tigervnc/common/rfb/Configuration.h:164:18: note: hidden overloaded virtual function 'rfb::VoidParameter::setParam' declared here: different number of parameters (0 vs 1)
    virtual bool setParam();
                 ^
/home/shade/dev/tigervnc/common/rfb/Configuration.h:256:18: error: 'rfb::BinaryParameter::setParam' hides overloaded virtual function [-Werror,-Woverloaded-virtual]
    virtual void setParam(const void* v, int l);
                 ^
/home/shade/dev/tigervnc/common/rfb/Configuration.h:164:18: note: hidden overloaded virtual function 'rfb::VoidParameter::setParam' declared here: different number of parameters (0 vs 2)
    virtual bool setParam();

Since it is caught by the local system on most platforms.

Have a window that is sized to the remote screen.  Now shrink the window
vertically, making it shorter than the remote screen in one axis. The
vertical scrollbar appears. However, the horizontal scrollbar does not
appear, despite the rightmost ~24 pixels (Fl::scrollbar_size()) being
hidden by the vertical scroll bar.

Fix that.

For clarity, move the fullscreen checks into a separate `if` statement,
rather than keeping the size and fullscreen checks together.

I think the comment does a decent job of explaining and justifying the
check's logic, but if you require further convincing, perhaps this
alternate explanation will help:

  The check for the X-axis is

      if ((w() - (h() < viewport->h() ? Fl::scrollbar_size() : 0) < viewport->w())

  To be a bit more verbose and repetitive, we can split that ternary in to
  two separate checks, and add some comments:

      if (
             (w() -  < viewport->w()) // X needs a scrollbar
          ||
             ( (w() - Fl::scrollbar_size() < viewport->w()) && (h() < viewport->h()) )
             //( X doesn't need a scrollbar unless Y does ) && (  Y does need one  ) )
         )

  Within the "Y does need one" check, we don't need to worry about the
  case where `h() - Fl::scrollbar_size() < viewport-h()` is true,
  because if both axes are saying "I don't need a scrollbar unless
  you do", then neither needs one.

They finally added kVK_RightCommand, so our workaround needs to be
conditional.

macOS actually uses the alpha channel on windows, so we can get visual
artifacts if we feed it bogus alpha data. This filtering unfortunately
causes some CPU usage, but it's necessary until we can make sure the
framebuffer always contains proper 0xff for alpha.

We won't always be on the primary monitor, so check which color space
we're actually using right now. For offscreen stuff we assume a standard
sRGB color space.

The system expects these to be immutable, so changing the data after
creation only works in some special cases. We need to recreate the
CGImage object each time we've changed something.

It seems to be more efficient.

Some backends don't like empty draw operations, so have an early check.

Width and height of a cursor are received as U16 from network. Accepting full range of U16 values can cause integer overflows in multiple places.

The worst is probably VLA in CMsgReader::readSetXCursor:
  rdr::U8 buf[width*height*4];

The width*height*4 can be too big to fit on stack or it can overflow into negative numbers. Both cases are undefined behaviour. Following writes to buf can overwrite other data on stack.

Setting the limit to 1024 which should be still more than enough.

Unlimited ulen and plen can cause various security problems:
  * Overflow in `is->checkNoWait(ulen + plen)` causing it to contine when there is not enough data and then wait forever.
  * Overflow in `new char[plen + 1]` that would allocate zero sized array which succeeds but returns pointer that should not be written into.
  * Allocation failure in `new char[plen + 1]` from trying to allocate too much and crashing the whole server.

All those issues can be triggered by a client before authentication.

Currently it proceeds only if there aren't enough data in queue and then it blocks waiting.
Also the required amount to receive from network is (ulen + plen), not (ulen + plen + 2).

This allowed not authenticated clients to deny service to everyone.

Otherwise it gets leaked which would allow even not authenticated clients to exhaust server memory.

Everyone else seems to get by with using 0600, so let's do the same.

It's not enough that we detach from the shared memory, we must also
tell the X server to do so for it to be freed properly.