Move reconnection into the handleDisconnect: method.
Only reconnect if the number of reconnect attempts doesn't exceed
a specified limit.
A manual call to connect should reset the reconnect attempts counter.
We can now safely auto-reconnect if the connection fails whilst connected.

This makes it easier for clients as this can happen whenever the app 
goes into the background or the device is locked.

In the cases where there is no internet connectivity, we will still 
end up retrying at least once but this will fail and as we were not
previously connected at the point of the second failure, we will no
longer continue trying to reconnect.

We are further protected from infinite retries due to our internal
retry limit.
Always attempt to reconnect if we have reachability.

Ideally we would also implement our own retry limit but for the sake
of the sample app I've omitted this.
Always perform reachability checks on disconnection *unless* we've
disconnected due to a pusher error.
Made this comment more accurate
Introduce back-off delay mode for 4100-4199 errors.

Used this as an opportunity to refactor the reconnection parameters - 
faced with adding some kind of "back off" flag, coupled with the fact
that you still had to pass a reconnect delay when you weren't going to
reconnect, using an enum to describe the reconnection "mode" seemed
much nicer.

The back-off mode is linear, we just multiply the configured delay by
the number of the attempt, which should more than suffice.
Switch missing default
Merge branch 'release/1.5' into introduce-retry-limits.

This should get the branch building on Travis CI.
Reconnect immediately on connection failure.

This removes any delay in reconnection when waking the device up.
Merge pull request #123 from lukeredpath/introduce-retry-limits

Introduce retry limits on automatic reconnects