There seems to be a locking problem in libvncserver, with respect to how
condition variables are used.

On certain machines in our lab, when using a vncviewer to view a display
that has a very high rate of updates, we will occasionally see the VNC
server process crash.  In one stack trace that was obtained, an assertion
had tripped in glibc's pthread_cond_wait, which was called from
clientOutput.

Inspection of clientOutput suggests that WAIT is being called incorrectly.
The mutex that protects a condition variable should always be locked when
calling wait, and on return from the wait will still be locked.  The
attached patch fixes the locking around this condition variable, and one
other that I found by grepping the source for similar occurrences.
Signed-off-by: Charles Coffing <ccoffing@novell.com>

x11vnc: add Files mode to user controlled input. more ultra/tight filexfer tweaks.  rfbversion remote control. noncache/nc unixpw user opt.

x11vnc: watch textchat, etc in unixpw, implement kbdReleaseAllKeys, setSingleWindow, setServerInput. watch for OpenGL apps breaking XDAMAGE.

LibVNCClient: some users do not want to get whole-screen updates; introduce client->updateRect for that

x11vnc: -reflect, -N. -ncache, FINDDISPLAY, FINDCREATEDISPLAY, improvements.  MODTWEAK_LOWEST workaround.