Testing patch with Travis

This patch prevents the occasional failure of the unbind test on Travis. The problem was a race condition so it did not fail every time. This failure can be confirmed by running Travis on the current master branch with the unbind code in it.

The failure would usually happen with this stack.
  at null._ioevents (/home/travis/build/f34rdotcom/zeromq.node/lib/index.js:231:22)
  at Socket._flush (/home/travis/build/f34rdotcom/zeromq.node/lib/index.js:461:23)

It would also sometimes fail inside of zmq library as an assertion in mailbox.cpp or signaler.cpp

I have run several builds and so far the problem is gone. If one were to force a Travis build on the master branch it will fail after running it as few as 3 times. You are welcome to do this to confirm the bug I am describing exists as a sanity check.

 I have seen another race condition failure in test.socket.messages.lateconnect.js but one I do not think is related or as serious. I feel it is related to an insufficiently long timer in the test but it would be good to confirm this just in case by testing this patch in another branch and fixing the timer then running Travis 10 times to confirm it passes every time. Then merge this and fix the timer in a another patch to keep it separate and clean.

The state will only be > 0 when we are binding or unbinding currently. This will only happen if we call "unbind" or "bind" currently for example on line 253 in this file. This line will cause js to stop exicution at this point and let the async function proceed in the background. This would also let other async js code run that could call a flush but we do not want to actually call any zmq functions or we would cause exceptions with multiple threads inside of the same zmq context. When the unbind finishes it will call a flush making sure we flush any data that may have been added by other code during this time. Best I can tell when I worked this through the last time and it was a bit of brain time to follow it I did not see any condition causing a lockup or anything that prevented a flush.

If however someone changes the flag meaning down the road this would be a big problem. And any other calls that do async operations on zmq lib "must" also do the flush and tell by using this flag that something is in flight.

Sorry I did not discribe all my thought processes better.

Re
 Sean M