* Test for batching ACL.
* Batch events from sync within BanList.
* Introduce the BanList.batch event to the BanList emitter to let Mjolnir sync after new events have been added from sync.
Fixes#203
This is an experimental ruleserver that will serve the combined rules from
the active policy lists to a Synapse module over a web api.
This makes it easier to communicate changes in policy lists to Synapse workers
that do not have an immediate view over all of the policy rooms at
the same time.
This also allows us to express moderation actions to the homeserver
beyond what is currently expressible via MSC2313 policy
lists.
We do this so that there is only one source of truth for which rules
are active and it simplifies de-duplicating rules of conflicting event
types (e.g. m.room.rule.user vs m.policy.rule.user).
The reason for doing this is because otherwise there may be duplicate
rules under different state types for the same entity.
This simplifies the process of modifying or invalidating rules affecting
an entity because the rule with the most recent type will always be
preferred.
Only shows changes to lists made by other accounts (than the one used by Mjolnir).
Displays when rules are added, removed and modified by either replacing the state event or redacting them.
This is so that the context of failing callbacks are not lost.
We also await during pagination and not after so that if a call to the callback fails, we will not call it again.
Related to https://github.com/matrix-org/mjolnir/pull/132.
The old code would call `/sync` with this filter. If a token was
provided in the response of `/sync` for earlier messages, it would
then use this same filter to call `/rooms/messages`. However, this
filter does not do anything on that endpoint when we know the id of
the sender, as it requires a RoomEventFilter and there is no warning
or error from synapse about the structure of the filter being wrong.
This was not noticed until after the related PR because `/sync` with
the filter would usually be able to provide a user's
entire history in one room. This is because in most cases a user is banned/redacted
shortly after joining a room.
In the case that `/rooms/messages` was called for more events, the method would
always paginate the timeline up until the limit or the end of the room
history, which is only the expected behavior when matching the sender
with a "glob".
* Simply redacts any media sent to the room, by anyone
* Meant to serve as a temporary measure to prevent image spam,
in conjunction with FirstMessageIsImage
Marco Cirillo