Fix recv ordering problem

There were multiple errors in recv handling:

1. Multiple receivers on the same socket would result in the first receiver
   waiting and eventually getting data, and the rest of the receivers being
   told to wait but never getting any data even if available because they
   were not queued properly.

2. After successfully receiving data on behalf of a waiting receiver and
   delivering that data, other waiting receivers would never get data
   because the receiving socket was dropped from the pollset after the
   recv().

3. With the right timing, a new receiver might be able to intercept data
   that should have gone to an already-waiting receiver. For this to
   happen, the new receiver would have to enter the driver and perform a
   non-blocking socket recv() call just as data arrived on the socket, and
   for the new receiver to get the data we assume, perhaps incorrectly,
   that in this case the recv() call would take precedence over event
   polling notifying older receivers of available data.

Fix these problems and add a new test to cover the first 2 issues. To
ensure the 3rd issue never happens, the code now queues any new receivers
whenever other receivers are already waiting, and the new tests ensure that
queued receivers get data in the correct order. But because of the precise
timing involved for the 3rd issue, this potential problem is not tested.