Implement multi-community (fixes #818, fixes #5340)

[Nutomic]

• [x] Database migrations
• [x] Api endpoints
• [x] Parameters and query changes for PostView, to browse posts in multicommunity (blocked by #5429)
• [x] Federation (see Piefed FEP)
  • Piefed implements this in a very complicated way, by adding a separate kind of group actor with public keypair, moderators, inbox etc. That is very complicated for little benefit, instead Im adding a simple collection which gets synchronized
  • Currently Piefed has some bugs in this area and some things are inconsistent with the spec, so its not compatible yet
• [x] Max length for multi-community name and allowed characters
• [x] Check for removed/deleted community when updating multi-community. Also only allow public communities to be added (maybe Unlisted or LocalOnlyPublic would also be fine?)
• [x] Regular sync with other instances
• [x] Fetch multi-comm via resolve_object (with workaround)
• [x] Update local_site.default_post_listing_type and local_user.default_listing_type to include featured
• [x] API test case
• [x] Support delete, change name?
• [x] Get rid of todos for ListingType::Suggested
• [x] Maximum 50 communities per multi-comm (because following a multi-comm means sending follow request to each community which is expensive)
• [x] When unfollowing multi-comm also unfollow contained communities (only if they are not part of another followed multi-comm)
• [x] Federation for multi-comm follow/unfollow
• [x] Federate multi-comm updates to followers, then update user community follows
• [x] Update tests
• [x] Properly adjust community subscribes when remote multi-comm is updated

[Nutomic]

Right the removed/deleted filters for read functions were missing, added those now. Also changed the update endpoint to filter out removed/deleted communities instead of throwing error.

[Nutomic]

About federation, sending update activities for changes to multi-community is not that simple. The way its implemented now multi-comms are associated to a person, so it would mean following the person and also getting a lot of unrelated activities for new posts and comments. Piefed did it by implementing a new actor type (similar to community or person), which means a lot of overhead for something relatively minor.

Another possibility would be to associate multi-comms with the instance instead of a person. Its not clear who would send the follow in that case, plus it means that updates to all multi-commns get sent. It could work by sending updates for all local multi-comms to all known instances, and the receiving side ignores those which havent been fetched already.

[Nutomic]

That's unavoidable I think. If we let people follow multicommunities, then that is a specific actor type similar to communities. Its also distinct from following a person (even if we did support that) because you might want to follow a specific multi-community created by a person, but not all of the ones they created. There's probably no way around adding MultiCommunity as a followable actor type.

Its not entirely clear how this should work. Follow implies that communities from followed multi-comms would show up in the subscribed feed which is probably not what users want. To me it makes more sense to mark multi-comms as favorite so they get listed in the sidebar and can be browsed separately. Still the user needs to somehow follow individual communities which are part of the multi-comm to receive new posts. So maybe Piefeds approach makes sense after all...

[dessalines]

Follow implies that communities from followed multi-comms would show up in the subscribed feed which is probably not what users want.

Yep this is a unique type of follow that doesn't affect front page feeds, but would allow updates to that multicommunity to be pushed to instances with users that follow it, and allow local representations across different servers. Seems unavoidable.

[Nutomic]

Alright made a lot more changes which should address all the feedback and implement all the functionality. Still need to expand the api test if the main code looks okay. Please have a look.

[Nutomic]

One thing still missing compared to other types is a MultiCommunityView. Is it worth adding that?

[dessalines]

One thing still missing compared to other types is a MultiCommunityView. Is it worth adding that?

Hrm... I didn't think about that. It belongs to a person and an instance, so it would be useful to have those come back in the API responses. Simple inner_joins work.

[Nutomic]

Added MultiCommunityView which contains owner. Didnt add instance because PostView, CommunityView etc also dont contain that. Would be neat if it would directly contain Vec<Community> as well, but that would require complicated raw sql queries again.

[dessalines]

Would be neat if it would directly contain Vec<Community> as well, but that would require complicated raw sql queries again.

Remember views can't and shouldn't contain lists, they should only be 1-1 joins.

[dessalines]

Besides the above, and merge conflicts, it looks good. Feel free to merge once that's addressed and tests are passing.