REFACTOR ActivityPub serializers
What does this MR do and why?
⚠ ️ This is the second part of the merging of the overarching MR, please read its description if you want to understand what is happening here. :) Feel free to ask as many questions as you want if you want to understand the protocol!
ActivityPub is all about JSON : it's used in endpoints to display
information about various actors (the ActivityPub term for any kind of
resource that generates a feed), as well as in messages exchanged
between servers about what those actors are doing ("activities", in
ActivityPub terminology). For that reason, one of the very first thing
we did when implementing ActivityPub was creating serializers for it, in
the ActivityPub namespace, in the merge request
about displaying the first actor's profile and outbox.
Those serializers are only used by ActivityPub features behind a
feature flag, for now.
While working on additional features, though, it was made clear that the architecture for those serializers was not going to work for everything. First, an actor and an activity usually have different boilerplate, so it helped distinguish them through an ActorSerializer and an ActivitySerializer, both inheriting from an ObjectSerializer (referring to the ActivityStreams' Object type).
Second, using BaseSerializer plural features does not work here.
ActivityStreams paginated collections are
their own beast.
They are linked lists, with a dedicated document serving as index and
providing links to the various resources - it just does not fit what
BaseSerializer allows to do. So an other serializer,
ActivityPub::CollectionSerializer has been added to handle them. This
simplifies a lot the previous architecture which was fighting to make
this fit BaseSerializer plural feature through a lot of overriding.
This commit refactors the ActivityPub serializers to reflect that and pave the way for the features coming after. It does not affect existing code (the API used so far for the releases actor is unchanged).
How to set up and validate locally
This MR does not do much by itself and is part of the whole feature from the overarching MR. You can follow its way to set up and validate locally to test what is related to this MR in the process.
Alternatively, you can use the procedure from the previous feature to verify it still works with no breakage (note that you need to activate the activity_pub and activity_pub_project feature flags).
Related to &11247