This class will perform in the same manner as Synapse did before,
unless a custom PresenceRouter module is configured. If one is,
then it will pass through the calls from Synapse to that module.

… PresenceRouter

This commit asks the PresenceRouter for any users - in addition to those
from users that they share a room with - that should receive the given
presence updates.

These methods are called when routing new presence updates around as
they come in.

* `get_interested_parties` is called when figuring out which local and
remote users to send presence to. For local users, their sync streams
will be woken up.
* `get_interested_remotes` is specifically for figuring out which remote
user(s) a given presence update needs to go to.

…et of users

This function is useful for 'catching up' a user if you've just starting directing
presence updates their way. Sending the current presence (excluding offline) for
each user before you start sending them diffs ensures the target has the right
presence state for each user immediately.

This effectively just forces a presence initial_sync for the user.

This big ol' change does three high-level things:

1. It modifies `_get_interested_in` to ask the loaded PresenceRouter if
there are any users - in addition to those that share a room with the
user in question - that it thinks should have their presence status
queried. PresenceRouter can either return a Set of users, or "ALL".

2. It modifies `get_new_events` (which is mainly run when a user is
syncing and needs to check for presence updates) to support receiving
"ALL" from `_get_interested_in`. What happens then depends on whether a
`from_key` was provided to `get_new_events`. We also now call
`get_users_and_states` to filter the UserPresenceState objects after
querying ALL of them from a given `from_key`.

3. It also modifies `get_new_events` to take into account whether the
syncing user is included in
`ModuleApi.send_full_presence_to_local_users`. If so, then we're going
to send them all current user presence state (filtering it through
`get_users_for_states` again). We then remove the user ID from the set
to ensure the same doesn't happen on the next sync.

This is mainly all to support redirecting presence for local users as
they sync, though the same method is called for appservice users.

…dler

Co-authored-by: Erik Johnston <erik@matrix.org>

…sence_hook

…sence_hook

This commit refactors _filter_all_presence_updates_for_user a little bit to allow
taking from_key as an optional parameter. The advantage of this function is that
we filter presence updates through PresenceRouter. Turns out we had a code path
(no from_key, return presence for ALL users) that ended up not filtering through
PresenceRouter.

Having both code paths end in _filter_all_presence_updates_for_user not only makes
things a little easier to follow, but it ensures filtering always happens.

I also took the bit where we remove the user from
ModuleApi.send_full_presence_to_local_users out of
_filter_all_presence_updates_for_user to clean it up a bit further.

…uter

This test was more concerned with the functionality of PresenceRouter, so I moved it
to the PresenceRouter test file instead.

The current default_config method didn't quite work for the test we just moved in,
(it negated any use of @override_config). So convert it to an @override_config
call instead.

…sence_hook