[Story] Preview for effects of policy list subscription

[Gnuxie]

Description

As a Draupnir moderator, when I find a new policy list to watch, I should be able to preview the effects of watching the list before making a decision to watch it. Effects include any users that will be removed from protected rooms, any servers that would be banned and their effected users in protected rooms. We will also need to be notified of the effects this will have on other protections that might use policy rooms. Then we can click the confirm or cancel the application of the changes.

Acceptance criteria

• When previewing changes to policy subscription, I can see a summary of all the actions that protections would make
• I can decide to accept or cancel the changes

Issues

• Make policy list collaboration easier by offering to preview effects before subscribing Draupnir#192
• Make banlist collaboration easier by offering to preview effects before subscribing matrix-org/mjolnir#228
• (maybe) Preview the effects of enabling a protection Draupnir#359
• (stretch) Improving ban previews for policy rooms such as CME Draupnir#803

Dependencies

• [Story] Add capability management to Draupnir and MPS #6 - partially, since the dummy (config.noop replacement) capabilities will need to exist and have their renderers available

Total Pain

40

PRs

• Add simulated capabilities. Gnuxie/matrix-protection-suite#86
• Update for simulated capabilities from MPS v2.10.0 and add their renderers, commands. Draupnir#727
• Intorduce projection intent projections for member ban and server ban protetions Gnuxie/matrix-protection-suite#100
• Add preview to watch command Draupnir#1007

Release

• https://github.com/the-draupnir-project/Draupnir/releases/tag/v2.8.0

[Gnuxie]

The problem that must be considered before we implement this is that for some protections we have a bad model of "intent" state. This is demonstrated in the-draupnir-project/Draupnir#1001. For instance the intent state for member ban synchronisation is really a list of users and the rooms they will be banned wtihin. And this should be what is communicated to the user, not the capability renderer. The capability renderer is good for communicating failure and permission errors. But the intent state and the capability that will be used to make the intent effectual is what is important to communicate.

The same is true of the server ban syncornisation protection. In reality we just have a list of server we are denying from the protected rooms set as the intent state.

The other protections that are important to preview are the RoomTakedownProtection, and the HomeserverUserPolicyProtection. Similarly these suffer from the exact same issue of not being able to communicate intent state, which practically is a revision issuer (See #69).