Mjölnir as a banlist server

Nobody has claimed this yet.

MSC2313 defines "ban lists", e.g. state events designed to encode the fact that a user or a homeserver, or a room, etc. should be banned from e.g. a room. Mjölnir's `synapse_antispam` module implements a subset of this, but in a way that doesn't really work too well in multi-worker setups and might be fragile in case of high load.

After discussing with @turt2live, there's a way do handle things better.

# Requirements

- We want the next-generation of `synapse_antispam` to work in multi-worker setups without having to setup e.g. an additional database, as this would complicate the setup and extend the security perimeter.
- We don't want to add a database to Mjölnir, for the same reasons. State events should do the trick.
- We want the ability for the next-generation of `synapse_antispam` to receive the ban lists *without having to read it directly from rooms*, to ensure that `synapse_antispam` won't be frozen if, for some reason, federation is experiencing difficulties.

# Generation 2

- Mjölnir maintains an in-memory representation of the ban list (well, of the subset it implements).
- When Mjölnir starts, fetch the ban list state events from the relevant room and build the data structure.
- Whenever a ban state event is added, redacted or modified, Mjölnir updates the data structure.
- Mjölnir is in charge of resolving aliases.
- Mjölnir serves this ban list through a HTTP(S) server (we recently added one for other reasons, so it's already there).
- Synapse module v2 maintains an in-memory representation of the ban list.
- Upon startup, the list is empty. Anything goes.
- Every e.g. one minute, the Synapse module downloads a list of new rules/removed rules from Mjölnir.
- This ensures that all workers (eventually) have the same set of rules, without the need for a database/sophisticated IPC/...
- The Synapse module uses the Synapse Module API (which replaces the now deprecated Synapse Antispam API) to implement bans.

At this stage, we're not substantially changing the nature of bans that can be implemented, just making them much more reliable.

# Future evolutions

## Emergency access to ban lists

If federation is experiencing difficulties, this change will not be sufficient to ensure that new bans can be issued in emergency. However, this new architecture would be easy to extend to create a CLI tool or a Web API to communicate with Mjölnir and add (or remove) bans while side-stepping Matrix and federation.

This can be dangerous, so To Be Discussed.

## Sharing ban lists

MSC2313 suggests mechanisms to implement ban room sharing, aka one more step towards decentralized reputation. Once generation 2 has been implemented, we should be able to extend it with ban room sharing.

Start by locating the existing HTTP(S) server and the synapse_antispam implementation. Trace how Mjölnir currently reads and updates ban-list state, then review the Synapse Module API integration described here. Done means a generation-2 in-memory ban list can be synchronized to Synapse workers without an added database and remains reliable during federation difficulties.

Written by the indexing model from the issue text.