ADD worker and dependent services for ActivityPub subscription

What does this MR do and why?

⚠️ This is the second part of the merging of the overarching subscription MR at !132460 (closed) , 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!

This provides the worker performing the async resolution of inbox URLs, and sending the Accept activity to the subscriber's inbox.

The worker will be called from the inbox endpoint of our actor for releases, when the endpoint receive a Follow activity (this part will be added in a following MR). When it happens, the controller queues the worker, which will be responsible of:

• Retrieving the actor's inbox URL if we're only provided the actor profile URL
• Retrieving the third party server shared inbox if it's provided
• Sending an Accept activity to the actor's inbox to let them know we received their subscription
• Updating our subscription record to mark it as active

We won't use the shared inbox yet, but we will need it as soon as we send events when a new release is created, and the request we make to the subscriber's profile page is where that information is made available, so we save it right now.

The job is allowed to fail and is idempotent: restarting it if the inboxes were already resolved won't trigger an other third party request. If a subscription request somehow gets in for an already existing accepted subscription, we ignore it. And if the project is not public anymore, we delete the subscription.

The ThirdPartyError error has been added mainly to be nice to support, so that they don't queue errors in the issue tracker and start analyzing it only to realize again and again that it was just an unstable third party server and we can't do anything about it. Hopefully the name convey well enough the idea of "don't bother, it's not us".

After this is merged, we'll still need the controller, route and the service creating the subscription record.

How to set up and validate locally

The best is to use the full MR, which contains all commits for the feature, including this one, and steps to test it.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Query and query plan

For the #destroy statements:

Query:

DELETE FROM "activity_pub_releases_subscriptions"
WHERE "activity_pub_releases_subscriptions"."id" = 1

Query plan:

Delete on activity_pub_releases_subscriptions  (cost=0.15..2.17 rows=0 width=0)
   ->  Index Scan using activity_pub_releases_subscriptions_pkey on activity_pub_releases_subscriptions  (cost=0.15..2.17 rows=1 width=6)
         Index Cond: (id = 1)