Fix tightloop over connecting to replication server

* Fix check-newsfragment script

I previously broke this so that it always succeeded...

* more fixes

* fix newsfiles

So that it actually works. See https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass



Signed-off-by: Paul Tötterman <paul.totterman@iki.fi>

Otherwise if you have many workers they can easily take out master with
their connection attempts

If the client failed to process incoming commands during the initial set
up of the replication connection it would immediately disconnect and
reconnect, resulting in a tightloop.

This can happen, for example, when subscribing to a stream that has a
row that is too long in the backlog.

The fix here is to not consider the connection successfully set up until
the client has succesfully subscribed and caught up with the streams.
This ensures that the retry logic timers aren't reset until then,
meaning that if an error does happen during start up the client will
continue backing off before retrying again.

 Prevent showing non-fed rooms in fed /publicRooms v2

Revert "Prevent showing non-fed rooms in fed /publicRooms"

Config option to prevent showing non-fed rooms in fed /publicRooms

* Don't log stack trace when client has gone away during media download

* Newsfile

* Fixup newsfile

Fixes #4675.

* add trivial clarification about jemalloc

* switch from google.com to recaptcha.net

because https://developers.google.com/recaptcha/docs/faq#can-i-use-recaptcha-globally

Log tracebacks correctly

Fix backfill storing incorrect state for events

MSC 1866 - Use M_UNSUPPORTED_ROOM_VERSION for invite API

Handle errors when fetching remote server keys