[Task] Revisit and design the next steps for the appservice (multi-tenancy) mode of deployment

[Gnuxie]

Description

Currently there are only a couple of appservice deployments in the wild, and they are centered around providing bots to users much like a managed hosting provider would, but this is done in a very adhoc and informal way. This leaves the admins in a rather untenable position, because they essentially have to manage the service as though the users of each Draupnir are registered users on the admin's homeserver. To elaborate, any rooms that their Draupnir are protecting, the appservice admin's homeserver will be present within. So the admin has to be worried about the resource usage of both the appservice and their homeserver. They also have to concern themselves with the communities that their users are using the Draupnir within and whether they are legal or permitted by the admin. Which is duplicated work, since the user's own server admin already is having to concern themselves with these questions to provide them a Matrix account in the first place. This also leads back to a centralization problem, Draupnir functionality shouldn't be provided by a select few number of hosting providers. Instead, a user's own homeserver should be providing a Draupnir appservice for its own users. So that the responsibilities of the appservice admin are already the same, because they are already providing the homeserver for their own users.

To get around this, we must instead provide an appservice that sits much closer to the homeserver, when a user creates a Space, the appservice should offer to provision them a Draupnir for that space (via a DM perhaps). Perhaps it should even do this automatically and impersonate the user. This would free up a lot of the design work around administrative functions for the appservice if we can eliminate the concern (which i am struggling to word) of "how can I look after a user who is external to my own server as though they are registered on my homeserver, because the fact that they are using a draupnir on it materially means that they are much the same as a registered user on my homeserver".

The alternative is being forced to create tools to introspect on the number of rooms protected by a given Draupnir, what the room titles are, which is much the same tooling that is needed to monitor public registrations on a matrix homeserver.

Automatic provision

If we do provision Draupnir automatically for spaces, the control room should offer the ability to delete the instance in the DM, and the user should be able to invite an appservice bot user at any time to either give them a new Draupnir or reactive this one.