Ensure client attempts a reconnect on no PINGRESP

[keithamus]

Fixes #144

On every PINGREQ it sets this.pingResp to false, then if this.pingResp is still false by the next pingreq interval, it resets the connection. this.pingResp is set to true for the first ping.

Then, there is a handler on PINGRESPs which simply sets this.pingResp to true, so that a successful pingresp can be noted.

I'm not 100% happy with the tests - while they do test the functionality they're very "side-effecty".

[mcollina]

the build is failing on node v0.8, could you please fix it?

(I know 0.8 is old, but we still support it).

[keithamus]

I hate to say it but the tests are not consistently passing on my machine on origin/master or on my build, however they do pass. I think there might be some race conditions inside the test suite

Travis will pass if you re-run it on this branch, I believe.

[keithamus]

Build is passing now (I didn't change any code, I just amended the commit and force pushed until the build went green)

[adamvr]

Yeah, the timer dependent stuff really sucks, particularly on travis.

On calling _reconnect: I think a better idea is to kill the connection and let reconnect kick in automatically, so that reconnect options are respected.

[mcollina]

I think we should move all the timers to use sinon fake timers, they work great in simulating the passing of time.
Maybe that's another pull-request.

BTW, having fixed timeouts sucks. You really want random exponential backoff, as it ensure not all 10.000 clients reconnects at the very same time, crashing you again and again. (another pull request).
For this reason, I think that it's better to let reconnect kick in automatically.

[mcollina]

I'm merging this in and removing the call to _reconnect().

[mcollina]

@adamvr I'm releasing this and #143 as 0.3.5, if it's ok for you.

[adamvr]

👍 Fine by me