Fix the issue of receiving packets with tokio 1.0

[YushiOMOTE]

With tokio 1.0, I found a case that awaiting receive doesn't return sometimes even though packets are actually received. As none of the tests reproduces this issue, I added the new case.

One difference I found between new and old tokio is that it seems clear_ready in tokio 1.0 no longer wakes up the task, while clear_read_ready in tokio 0.2 does.

clear_ready (tokio 1.0): https://docs.rs/tokio/1.0.1/src/tokio/io/async_fd.rs.html#489-493 v.s. clear_read_ready (tokio 0.2): https://docs.rs/tokio/0.2.24/src/tokio/io/poll_evented.rs.html#299-314

After adding wake up logic, it works.

I'm not yet confident that this is the correct way to fix. Checking further.

[skrap]

This note from man zmq_getsockopt might be related:

Note
The returned file descriptor is also used internally by the zmq_send and
zmq_recv functions. As the descriptor is edge triggered, applications must
update the state of ZMQ_EVENTS after each invocation of zmq_send or zmq_recv.To
be more explicit: after calling zmq_send the socket may become readable (and
vice versa) without triggering a read event on the file descriptor.

Were you using a socket type which has bidirectional traffic? If so, it seems that we could perhaps perform a sendmsg and then never be woken to read.

[cetra3]

Yeah I think this does require a little experimentation to get it synonymous with tokio 0.2.

I'm OK keeping this PR open for the time being & pointing users to it if they run into problems. It may end up being the appropriate change, but warrants a bit deeper thought.

[elbaro]

Had the same issue with a SUB socket (which is I believe one-directional) and this PR fixed the problem.

[skrap]

Seems like we should take this, yes?