Serious side effect of #6299 (silencing salut so gabble can connect)

[Morgan Collett]

Ricardo Carrano wrote:

> Two premises (that need confirmation)
> 1 - It seems that running neither of two (salut and gabble) brings us
> some serious troubles (for now, at least).

In case you missed some of the mails, it turned out only Pippy needed
fixing in the short term, and that's now done as of Joyride-1701. We
should therefore be OK.

We need someone at 1cc to test whether that build does indeed notice the
schoolserver and keep salut off for 2 minutes while it tries to connect
to the jabber server. You would need some laptops on salut on the
appropriate mesh channel so you can see their absence running this
build, and you would need a schoolserver running the jabber server.
Also, try it with the jabber server disabled so you can verify the salut
buddies come back after 2 minutes (the time we disable salut).

> 2 - The fall back mechanism (if gabble then shut salut down) seems an
> easy fix.
> 
> So, my suggestion is that we just test the scenario where only " 2"  is
> activated. It should be an easy test to make.

Let me clarify how Presence Service runs the Telepathy Connection
Managers (CMs):

* Initially we had only gabble while salut was being developed.
* When we added salut, it was in such a way that the CMs could run
independently and simultaneously.
* However, with both CMs running there's nothing in the UI that shows
which connection a given buddy is on, or a given activity. So not all
the buddies in mesh view can be invited to a given shared activity, or
see a given shared activity.
* In the runup to Trial 2 (IIRC) we turned the simultaneous running of
CMs off, so that it would be clear that all buddies you can see at a
given time should be able to participate in a shared activity. You
therefore see either server buddies (gabble) or mesh buddies (salut).

The current algorithm, as it has been since then, is to start both
plugins (server_plugin talking to gabble, and linklocal_plugin to salut)
when Presence Service starts, and then whenever gabble succeeds in
connecting to the jabber server, stop salut (linklocal_plugin) and
whenever gabble disconnects from the server or otherwise goes away,
restart salut (linklocal_plugin).

This means that in practice, if you have a working jabber server
configured, Presence Service starts both, and salut succeeds in
"connecting" first. You then see mesh buddies for a short time, while
gabble is connecting to the jabber server.

Here's the key: *if* gabble succeeds in connecting to the jabber server,
*then* we stop salut. That is a problem in an overly busy mesh, because
we are not able to connect to the jabber server.

That's the meltdown scenario we are trying to avoid, by detecting the
evidence of a schoolserver on the mesh, and stopping salut for a short
while to give gabble a chance to connect.

This would only work if all the laptops did the same - so if a bunch of
laptops were fired up at the same time, they would all simultaneously
*not* run salut, succeed in connecting to the jabber server, and then
run using unicast, which should not overwhelm the mesh.

Morgan