_xcb_conn_wait: Shut down the connection on unexpected poll() events.

_xcb_conn_wait: Shut down the connection on unexpected poll() events.

If a client calls close(2) on the connection's file descriptor and then
flushes writes, libxcb causes a hang in the client.

Any flush eventually calls _xcb_out_send() with has the following loop:
   while(ret && *count)
       ret = _xcb_conn_wait(c, &c->out.cond, vector, count);

_xcb_conn_wait(), if built with USE_POLL, gets the POLLNVAL error. It only
checks for POLLIN and POLLOUT though, ignoring the error. Return value is 1,
count is unmodified, leaving us with an endless loop and a client hang.

XTS testcase Xlib3/XConnectionNumber triggers this bug. It creates a display
connection, closes its file descriptor, tries to send a no-op, and then expects
an error.
http://cgit.freedesktop.org/xorg/test/xts/tree/xts5/Xlib3/XConnectionNumber.m

If poll returned POLLHUP or POLLERR, we might see the same result.

If poll returns any event we didn't ask for, this patch causes
_xcb_conn_shutdown() to be invoked and an error returned. This matches the
behaviour if select(2) is used instead of poll(2): select(2) returns -1 and
EBADF for an already closed file descriptor.

I believe this fix both is safe and will handle any similar error. POSIX says
that the only bits poll is permitted to set in revents are those bits that were
set in events, plus POLLHUP, POLLERR, and POLLNVAL. So if we see any flags we
didn't ask for then something has gone wrong.

Patch inspired by earlier proposals from Peter Hutterer and Aaron
Plattner--thanks!

Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>