Current FedSocket implementation has a bunch of problems. It doesn't
have proper error handling (in case of an error the server just doesn't
respond until the connection is closed, while the client doesn't match
any error messages and just assumes there has been an error after 15s)
and the code is full of bad descisions (see: fetch registry which uses
uuids for no reason and waits for a response by recursively querying a
 ets table until the value changes, or double JSON encoding).

Sometime ago I almost completed rewriting fedsockets from scrach to
adress these issues. However, while doing so, I realized that fedsockets
 are just too overkill for what they were trying to accomplish, which is
 reduce the overhead of federation by not signing every message.
This could be done without reimplementing failure states and endpoint
 logic we already have with HTTP by, for example, using TLS cert auth,
or switching to a more performant signature algorithm. I opened
https://git.pleroma.social/pleroma/pleroma/-/issues/2262 for further
discussion on alternatives to fedsockets.

From discussions I had with other Pleroma developers it seems like they
 would approve the descision to remove them as well,
therefore I am submitting this patch.

* These are the first small steps for issue 2034 "Reports should send a notification to admins".
* I added a new type of notification "pleroma:report" to the the database manually (a migration will need to be written later)
* I added the new type to the notification_controller
* I made the view return the notification. It doesn't include the report itself (yet)

Validate the content-type of the response when fetching an object,
according to https://www.w3.org/TR/activitypub/#x3-2-retrieving-objects.

content-type headers had to be added to many mocks in order to support
this, some of this was done with a regex. While I did go over the
resulting files to check I didn't modify anything unrelated, there is a
 possibility I missed something.

Closes pleroma#1948

- log level reduction, if policy doesn't implement config_description method
- docs in dev.md

- revert UserAllowPolicy description
- MRF descriptions order

While taking a final look at instance.gen before releasing I noticed
that the release_env task outputs messages in broken english. Upon
further inspection it seems to have even more severe issues which, in
my opinion, warrant it's at least temporary removal:
- We do not explain what it actually does, anywhere. Neither the task
 docs nor instance.gen, nor installation instructions.
- It does not respect FHS on OTP releases (uses /opt/pleroma/config even
 though we store the config in /etc/pleroma/config.exs).
- It doesn't work on OTP releases, which is the main reason it exists.
Neither systemd nor openrc service files for OTP include it.
- It is not mentioned in install guides other than the ones for Debian
and OTP releases.

Fix object spoofing vulnerability in attachments

See merge request pleroma/secteam/pleroma!18

Resolve "Account cannot be fetched by some instances"

Closes #2236

See merge request pleroma/pleroma!3101

OStatus / Static FE access control fixes

See merge request pleroma/pleroma!3053

[#1668] App metrics endpoint (Prometheus) access restrictions

Closes #1668

See merge request pleroma/pleroma!3093

Resolve "Posts tagged with #NSFW from GS aren't marked as sensitive"

Closes #2242

See merge request pleroma/pleroma!3094

[#2261] FrontStatic plug: excluded invalid url

See merge request pleroma/pleroma!3106

Resolve "Can't message yourself in a chat (but can start it)"

Closes #2257

See merge request pleroma/pleroma!3099

Elixir 1.11 compatibility / Phoenix 1.5+

See merge request pleroma/pleroma!3059

Use Pleroma.HTTP instead of Tesla

Closes #2275

See merge request pleroma/pleroma!3113

Closes #2275

As discovered in the issue, captcha used Tesla.get instead of
Pleroma.HTTP. I've also grep'ed the repo and changed the other place
where this was used.