A user's e-mail address may be fluid, and the site "instance name"
may be strange or change regularly. There's no reason to use these
over the user's stable ID and the site's stable hostname for TOTP
parameters. Even if the system is built to TOLERATE changes (as it
is -- I tested it), it seems much more elegant to have these para-
meters as stable identifiers.

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3514

* Policies were put under a new module (Pleroma.Web.ActivityPub.MRF.Policy instead of Pleroma.Web.ActivityPub.MRF), but this wasn't changed in the Pleroma.Web.ActivityPub.MRF @mrf_config_descriptions
* I don't have a unit test to prevent similar problems in the future because I don't find a proper way to do it
    * The descriptions in the unit tests are defined in the unit tests, so if someone changes module names in the code, the tests wont see it
    * The list is generated in Pleroma.Docs.Generator.list_behaviour_implementations, but I can't do a check in the when clause of the function to see if the provided module is a behaviour or not.

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3509

The original approach to search in GIN indexes is to use
`to_tsvector(text)` in the WHERE clause of the query. According to
postgres docs [pdoc], this method does not make use of the index,
while `to_tsvector(config, text)` does. This commit changed the
query to use the two-argument `to_tsvector()`.

[pdoc]: https://www.postgresql.org/docs/12/textsearch-tables.html

To obtain the search config in use, we make a query to the db first.
The `::regconfig::oid` hack is needed because Postgrex does not support
regconfig type directly [postgrexbug]. I use the conversion from and to
`oid` instead of `text` because I tested in the actual DB and querying
using the conversion via `text` is slow just as the one-argument
`to_tsvector()` variant.

[postgrexbug]: https://github.com/elixir-ecto/postgrex/issues/502

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3519

Closes: https://git.pleroma.social/pleroma/pleroma/-/issues/2758

* To see what front ends are installed, it ls static/frontends. When this folder doesn't exists yet, it will return an empty array.
* Installing still works since the folder is created during installation already

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3510

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3512

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3508

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3507

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3504

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3505

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3503

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3503

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3500

Backport of: https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3499

This should fix setting the upload limit in the database as found in:
https://queer.hacktivis.me/notice/A8XUZp74Cg7eYNEMxU

This reverts commit 7d350b73f5.

This was a wasteful shortcut to MediaProxy.preview_url/1 and we don't
always want the preview_url in the metadata anyway.

Speeds up recompilation by reducing compile cycles

Speeds up recompilation by reducing compile cycles

Speeds up recompilation by limiting compile cycles

This is what Mastodon uses and might fix some link preview bugs I've encountered

Speeds up recompilation

Speeds up recompilation