Misc OTP issues

See merge request pleroma/pleroma!1567

activitypub: publisher: add (request-target) to http signature when POSTing

See merge request pleroma/pleroma!1569

MRF: fix up unserializable option lists in describe implementations

See merge request pleroma/pleroma!1568

Switch to pre-1.8 version of tzdata.

Closes #1183

See merge request pleroma/pleroma!1566

tzdata 1.0.0 requires Elixir 1.8.0, but we target 1.7. Fortunately
tzdata issues bugfix releases for pre-1.8.0 version.

Backport the describe API changelog entry to develop

See merge request pleroma/pleroma!1564

Preload thread mutes/bookmarks in user_statuses

See merge request pleroma/pleroma!1563

Preload thread mutes/bookmarks in get_context

See merge request pleroma/pleroma!1562

Also removes filtering for creates (was done on the database side
already) and filtering for the requested activity (moved to the database
side) from application side.

MRF Vocabulary

See merge request pleroma/pleroma!1559

MRF describe API

See merge request pleroma/pleroma!1561

Add configurable length limits for `User.bio` and `User.name`

See merge request pleroma/pleroma!1515

Mastodon API: Preloading and normalization optimizations

See merge request pleroma/pleroma!1558

Nicer formatting for safe_render errors

See merge request pleroma/pleroma!1560

tests for Web/ActivityPub/Relay

See merge request pleroma/pleroma!1557

tests for /web/mastodon_api/mastodon_api.ex

See merge request pleroma/pleroma!1554

- 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?)

config: remove legacy activitypub accept_blocks setting

See merge request pleroma/pleroma!1556

Anyone who is interested in dropping blocks can write their own MRF
policy at this point.  This setting predated the MRF framework.

Disabling the side effect (unsubscription) is still a config option
per policy.

Update AdminFE

See merge request pleroma/pleroma!1555

Now permits server configuration. Consider this ALPHA.

Add a changelog entry for !1552

See merge request pleroma/pleroma!1553