Improve Pixelformat handling

This is my result from looking at #205, which tried to force ARD to use BRG;16 instead of RGB32. This PR introduces a new class PixelFormat based on dataclasses to pass around those many values of PIXEL_FORMAT.

As usual I found some more issues on my way:

The Encoding.lookup() was not working for Encodings defined via negative numbers, but where looked up using a unsigned-int.
Pseudo-Cursors using RGB24 was not handles correctly
Simplified one location doing integer math
Improved and added some more debug logging
Add NullTransport.loseConnection required for logproxy

The last one is problematic and incomplete, but I currently have no idea myself how to fix it for real: The bigger picture is that currently stream handling is wrong in several cases: As neither TCP nor the RFB/VNC protocol defines any framing, all messages passed from client-to-server and server-to-client must be understood and handled. While testing with gvncviewer as my client connecting LibVNCServer-0.9.14/examples/pnmshow24 as my server via vnclog I noticed, that they negotiated many more pseudo encoding than vnclog understands and can handle:

<Encoding.TIGHT: 7>
<Encoding.PSEUDO_QEMU_EXTENDED_KEY_EVENT: -258>
<Encoding.PSEUDO_QEMU_LED_STATE: -261>
<Encoding.PSEUDO_DESKTOP_SIZE: -223>
<Encoding.PSEUDO_VMWARE_DISPLAY_MODE_CHANGE: 1464686185>
<Encoding.PSEUDO_QEMU_AUDIO: -259>
<Encoding.PSEUDO_CURSOR: -239>
<Encoding.PSEUDO_X_CURSOR: -240>
<Encoding.PSEUDO_QEMU_POINTER_MODTION_CHANGE: -257>
<Encoding.ZRLE: 16>
<Encoding.HEXTILE: 5>
<Encoding.RRE: 2>
<Encoding.COPY_RECTANGLE: 1>
<Encoding.RAW: 0>

The pnmshow24 server supports many of them, but not all:

rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFB)
Enabling NewFBSize protocol extension for client 127.0.0.1
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5669)
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFD)
Enabling full-color cursor updates for client 127.0.0.1
Enabling X-style cursor updates for client 127.0.0.1
rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFF)
Using tight encoding for client 127.0.0.1

The last one is problematic as this results in a FramebufferUpdate-Message with the Encoding.TIGHT pseudo-encoding, which vncdotool cannot handle:

INFO:twisted:x=3 y=3 width=8 height=7 <Encoding.PSEUDO_CURSOR: -239>
INFO:twisted:x=0 y=0 width=256 height=256 <Encoding.TIGHT: 7>
INFO:twisted:unknown encoding received <Encoding.TIGHT: 7>
INFO:twisted:x=181 y=48643 width=30721 height=60669 '<Encoding.UNKNOWN: 5785c57>'

Afterwards vnclog is out-of-synchronisation and starts logging many errors as most following bytes are seen as an unknown Server-to-Client message ID.

To handle this correctly vnclog needs to sit in-between of the client and the server and must rewrite some of those messages to filter out any AuthType, Encoding, … vncdotool does not understand.

That's too much for me to do as of now, but someone might work on that. At least the PR improves the situation, but there is more work to do. Feel free to merge now and create new issues for the newly identified issues — or delay this PR until we have some idea on how to fix them.

sibson / vncdotool

Improve Pixelformat handling #243