ConnectionManager: always allow event queueing while connecting

[SimonWoolf]

Even if was previously suspended or after a failed connection freshness check

The current behaviour is there so that after you go into suspended, and
starts new connection attempts every 30s, it'll still reject publishes
immediately unless/until it becomes connected again. But this results in
some slightly unintuitive behaviour post-device-wake -- an eg presence
enter might fail milliseconds before the sdk reconnects, because it was
never actually having connectivity issues it was just asleep, and it
would have been fine to queue it. Queueing messages for a few seconds
during a connecting cycle (and then failing them if the attempt fails
and the sdk falls back into the suspended state) wouldn't be so bad.

Made the analagous change to the suspended state as well because if you
just remove the connection.queueevents=false line in the freshness
check, but then it fails that and then can't reconnect and goes into
suspended, it would behave differently from if it goes into suspended
via the suspendTimer.

(TBH I've never liked how we mutate the states struct in this way in
various places. IMO would be a lot more elegant to have a completely
frozen states struct, junk the suspendTimer, and decide whether to go
into suspended just by special-casing disconnected in notifystate,
checking how long it's been since we were last connected, and
substituting suspended if it's been over 2 minutes, or something like
that. But that's a change for another time.)

I don't think this change is against the spec, which leaves this ambiguous.

[paddybyers]

I agree that it's messy that (was suspended but is now connecting) is actually a different state from (was disconnected/connected but is now connecting). I think we could tidy this up, but I'm not convinced yet that making them the same state with the same behaviour is going to be sensible in all cases.

[SimonWoolf]

I'm not convinced yet that making them the same state with the same behaviour is going to be sensible in all cases.

To be clear - are you objecting here to the specific change this PR makes (events can always queue during connecting, and if it was suspended they'll be failed when the lib moves back to the suspended state)? Or only to a possible future change to remove all the mutation?

(afaik there's no other behaviour differences except queueEvents + which state is reverts back to if the connection sequence fails)