[fix] This addresses the close/open/close/open test case.
[fix] This addresses the close/open/close/open test case.

The problem was that when you close the connection server side the spark will:

1. Send a `primus::server::close` packet to che client
2. Close the connection.

The client would then receive the `primus::server::close` packet first but as our
`primus.emits()` methods add a timeout to prevent websocket crashes it doesn't get
parsed and executed directly. While this messages is waiting in it's setTimeout
state the connections gets closed and will emit an end event which is also delayed.

Finally it's time for the `primus::server::close` to get processed and we close the
connection by doing a `primus.end()` this sets the `readyState` to closed and emits
the `end` event. In our test case we directly call `.open` again to re-start the
connection. This sets the `readyState` to `OPENING` again instead of closed.
connecting takes some time and during that our emitted `end` event gets processed
as the setTimeout ended. It calls the `incoming::end` listener and sees that the
connection is not closed as it checks the readyState handler. So it proceeds with
closing the connection which we just opened.

So the solution for this is to queue up the incoming `server::close` packet and
truely close the connection without triggering a reconnect.

STRML/primus,clanwqq/primus,basarat/primus,colinbate/primus,clanwqq/primus,beni55/primus,colinbate/primus,STRML/primus,dercodebearer/primus,modulexcite/primus,dercodebearer/primus,STRML/primus,dercodebearer/primus,colinbate/primus,modulexcite/primus,primus/primus,modulexcite/primus,basarat/primus,primus/primus,clanwqq/primus,basarat/primus,beni55/primus,beni55/primus,primus/primus