Mostly to avoid long restore times thanks to an index not being built
before it's needed by restoring the DB schema first.
https://blog.freespeechextremist.com/blog/activities-visibility-index-slowness.html
Also updates backup command to compress DB backups, removes Pleroma
users's home directory, replaces "role" with "user" in PostgreSQL contexts
since they are the same now.
It will check reachability for an instance deemed unreachable at the following intervals:
4 attempts, once a minute
4 attempts, once every 15 minutes
4 attempts, once every 60 minutes
4 attempts, once every 8 hours
4 attempts, once every 24 hours
This should be effective and respectful of the resources of instances on the fediverse.
We have the Oban Pruner plugin enabled to keep the Oban Jobs table from growing indefinitely. It prunes every 15 minutes, but this will interfere with our ability to enforce uniqueness on the ReachabilityWorker jobs for a time period longer than 15 minutes. The solution is to exclude the ReachabilityWorker from the pruning operation and instead schedule a custom job that will prune the table for us once a day. The ReachabilityPruner cron task will clean up the history of the ReachabilityWorker jobs older than 6 days.
Ensure the job was queued, remove the other test validation. We already prove elsewhere that Pleroma.User.delete/1 works, so repeating that here is a waste.
It is not useful to call maybe_federate() with the processed
activity, because it will only record the activity id, and put
it into the queue. When the job is invoked, it reads from the database
for the activity. This means the changes we just made will be
discarded.
In this commit, I moved the stripping and anonymizing procedures
to Transmogrifier.prepare_outgoing, which is called after the
federator reads the activity from the database.
For protected branches, it seems now just CI_JOB_TOKEN is not enough.
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/36898#note_38415655
According to this, the CI_JOB_TOKEN is based on whoever created the
job and creating a pipeline on a protected branch requires special
permissions. Somehow this still did not work for other people who
merged, even though they had access to the docs repo.
Also return 404 when the user who sent the activity is believed to be
deactivated. It was already an error, now it just returns a better
reason than "Invalid request". Also send proper errors when either
user is not known at all.
