Managed Mjolnirs are being informed of every event sent to the appservice

[Gnuxie]

The mjolnirs will still compare the event against their joined/protected rooms deeper in the chain, so they won't act on any events in rooms they're not joined to or protecting, but this still is problematic and we should have defence in depth. https://github.com/matrix-org/mjolnir/blob/818e4cf3153015591b5175d584f542df10e7951b/src/Mjolnir.ts#L533-L558 https://github.com/matrix-org/mjolnir/blob/818e4cf3153015591b5175d584f542df10e7951b/src/ProtectedRoomsSet.ts#L176-L178

Inspiration should be taken from bridges on how they manage tracking of rooms. The thing is you shouldn't do this naively because it does duplicate effort. Mjolnir instance already track which rooms they are joined to and are protecting, we just don't have a way to map from a roomId to a set of Mjolnirs that are joined to that room.

https://github.com/matrix-org/mjolnir/blob/818e4cf3153015591b5175d584f542df10e7951b/src/appservice/MjolnirManager.ts#L99-L104

[Gnuxie]

Loosely related https://github.com/matrix-org/mjolnir/issues/411

[Gnuxie]

One way to do this is to:

• Provision bridge intents ourselves (whether we extend matrix-appservice-bridge or wrap the bridge class or provide some kind of injection API is TBD).
• Special kind of intent client that has the same listeners as matrixEmitter it is just transparent with respect to whether the events are sourced from /sync or appservice magic
• The intent only emits events when .start has been called like the bot-sdk syncing client
• We keep a persisted cache of the joined rooms for each intent. We always update this cache when we notice the intent being added/removed from rooms.
• When the intent is created, we call joined_rooms and shouldn't have to again.
• We recognize that although the transactions api in theory ensures the appservice is informed about all events, this isn't always the case, state resets happen and we already had a misconfiguration issue on mjolnir.matrix.org where Synapse "forgot the appservice existed".
• To counter this whenever we get an error for "user not in room" or "user banned" etc we invalidate the cache for that intent and recalled joined_rooms. This has to be a hidden process that is always active regardless of whether .start has been called and the intent is "running".
• We need to decide on the semantics of .start and .stop, does the appservice queue events while the intent has been stopped? Or are we free to discard them?

[Gnuxie]

Technically is blocked on #415 but if you just use the data store interface you'll be able to get most of it done