Mjolnir as an appservice

1. AppServices are not informed about events they have sent (whereas a client syncing does).
This is important because we rely on this behavior (in Mjolnir) as a cheap way to avoid inconsistency. For instance, when adding a rule to a policy list, we do not update the model policy list until we have received the rule down from sync.
Currently managed by
- https://github.com/matrix-org/mjolnir/pull/345
- Some way to split mjolnir code out from the main Mjolnir instance and have a matrix-bot-sdk client based .onEvent system and an asppservice .handleEvent system.

2. List short codes need isolating, i.e. they only apply if mjolinr is able to post rules into the list. There’s going to be a lot more Mjolnir’s in the universe and currently watching someone else’s list will also make Mjolnir use its shortcode.
We should also consider [MSC3784](https://github.com/matrix-org/matrix-spec-proposals/pull/3784) when list creation is refactored. .

3. List creation needs to make the room public but avoid assigning an alias, people aren’t going to know what the policy room is for until they have used it, so they won’t be able to give it a good alias and there won’t be many short aliases available (at least on matrix.org) which will result in frustration and errors. Avoiding this currently by just making them one to start with (without an alias) via some glue code.

4. Either a change to the default configuration (for autoJoinOnlyIfManager which is false, but being false means that it tries to load from a group (a community which are not even in the spec anymore), which causes a crash. We can change it to a space but it’s still a bit weird, is a requested feature though. Managed by:
- https://github.com/matrix-org/mjolnir/pull/338

5. Persist which mjolnir's have been commissioned by which users and add the code to start the mjolnlir's we created previously at start up. This will involve stealing from the fragmented storage layers of bridges https://github.com/matrix-org/matrix-appservice-irc/tree/develop/src/datastore https://github.com/matrix-org/matrix-appservice-discord/tree/develop/src/db

6. Health monitoring of provisioned mjolnirs - need to track and restart them, tell us of failures. Probably part of a bigger issue with tracking failure in mjolnir in general. The only way to make a serious error visible is by `logMessage`, and that might not be good enough here.

Start by separating the six requirements and reviewing the referenced Mjolnir pull requests 345 and 338. The issue also points to the matrix-appservice-irc datastore and matrix-appservice-discord db paths for persistence examples. This needs separate scope and acceptance criteria before a newcomer can identify a bounded change or determine when it is done.

Written by the indexing model from the issue text.