Favorites were paginating wrongly, because the pagination headers
where using the id of the id of the `Create` activity, while the
ordering was by the id of the `Like` activity. This isn't easy to
notice in most cases, as they usually have a similar order because
people tend to favorite posts as they come in. This commit adds a
way to give different pagination ids to the pagination helper, so
we can paginate correctly in cases like this.
the PostgreSQL query planner is easily confused due to the complexity of
certain queries we make. while we plan to simplify these queries through
unification of activities and objects, we are not yet there. it has been
discovered that using a precalculated list of deactivated users encourages
the query planner to prefer simpler indices instead of the
activity_visibility index.
accordingly, drop the subquery and precalc the user list instead.
- Try to normalize the activity instead of object wherever possible
- Put the `user` key on non-home timelines as well so bookmarks and
thread mutes are preloaded there as well
- Skip trying to get the user when rendering mentions if the id ==
as:Public or user's follower collection
- Preload the object when getting replied to activities and do not crash
if it's not present
This almost solves the problem of Pleroma hammering the db with a lot
of queries when rendering timelines, the things left are
1. When rendering mentions and the user is not in cache, save it for
later and request all uncached users in one go
2. Somehow get rid of needing to get the latest follow activity to
detect the value of `requested` in a relationship. (create a database
view for user relationship and cache it maybe?)
Add a table to store activity expirations. An activity can have zero or
one expirations. The expiration has a scheduled_at field which stores
the time at which the activity should expire and be deleted.
