Convert vnclog from by-pass proxy to inline proxy

[pmhahn]

Please include the following information:

vncdotool version
1.1.0-dev

VNC server and version
LibVNCServer-0.9.14

Steps to reproduce

ppmmake '#f70' 640 480 > ./dummy.ppm
/tmp/vncdo/libvncserver-LibVNCServer-0.9.14/examples/pnmshow ./dummy.ppm &
vnclog -v -s localhost:0 ./log.vncdo &
gvncviewer localhost:2

Expected result
vnclog should be able to log the interaction between gvncviewer and pnmshow

Which erroneous result did you get instead

INFO:twisted:unknown encoding received <Encoding.TIGHT: 7>

Additional information
While #243 added NullTransport.loseConnection required for logproxy, it noticed this issue: 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-synchronization 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.