Fix second simultaneous read (parallel paramiko issue)

https://github.com/eventlet/eventlet/issues/94

Because of the way paramiko utilises a client thread to manage its
communication, it's not been compatible with eventlet when run in
parallel.

It's not the only place these problems would arise.

This stemmed from the reuse of a fileno by the underlying OS.
Because listeners are registered against this descriptor, it would
be possible for old listeners to receive events destined for newer
descriptors; occasionally code would attempt to utilise the new
descriptor from a different greenlet, giving rise to the 'second
simultaneous read' problem.

Whenever a Python object is created to wrap one of these filenos,
we now signal the hub in order that it can correctly obsolete
extant listeners against that fileno. This is a fairly tricky
operation, due to the way that listeners' threads are interleaved
with the hub's operation - there are a number of small fixes here
to defend against one listener from effectively obsoleting another
when an event is pending against it.
hubs: defang after remove; related to second simultaneous read issue

https://github.com/eventlet/eventlet/issues/94

We have to defang the listener after removing it from the hub

Otherwise we never actaully remove it from the hub and get a return of the
second simultanous read.

This should fix this issue.

Turn off __builtin__ monkey patching by default

The reason is that eventlet.greenio.GreenPipe tries to
adapt an original file f, and performs the following check
isinstance(f, file) f is an original file object with file
is now our file method. This fails causing TypeError

nova-api exercises this

Fix up zmq to use the extended add signature

Having heard no problems relating eventlet and zmq,
I'm not going to dive in and drop random pataches against
it. If the 'Second simultaneous *er' crops up against
zmw then we at least now have the machinery to
address it.