Created attachment 354171 [details] [review]
telepathyClient: Don't conflate network- with account changes

On startup, we need to pick up both the initial network status
as well as the account status (so we identify the user and
connect rooms when the account is already connected, for
example when restarted after a crash). We currently cover
both cases when handling changes to the network availability,
however as we are about to monitor more network changes, we
may end up reinitializing accounts that are already connected.
While that shouldn't break anything, we can avoid the unnecessary
work by handling network- and account status initialization
separately.

Created attachment 354172 [details] [review]
telepathyClient: Use GNetworkMonitor::network-changed signal

Unlike notify::network-available that is emitted when the availability
of a default route changes, ::network-changed is emitted on any network
changes, for example when previously unavailable ranges become available
after connecting to a VPN network. As this may well be the reason for a
previous connection failure, it makes sense for us to reconnect accounts
in response.

Created attachment 354173 [details] [review]
application: Give up on connection failure

We do the best we can to establish a connection, if the connection still
fails, then retrying endlessly is unlikely to turn up a different result.
Except that telepathy apparently disagrees, and keeps trying anyway;
stop it from doing that by explicitly setting the presence to offline,
until the network changes and it becomes worth checking again.

Attachment 354171 [details] pushed as a9ed3bb - telepathyClient: Don't conflate network- with account changes
Attachment 354172 [details] pushed as 4e6929e - telepathyClient: Use GNetworkMonitor::network-changed signal
Attachment 354173 [details] pushed as c1b46a0 - application: Give up on connection failure