Makes downstream logic simpler and although we may look-up some events
we don't use, the lookup is all done in one go instead of fetching events
from event_ids in a couple different places.
See https://github.com/element-hq/synapse/pull/17320#discussion_r1647701997
```
synapse/federation/federation_server.py:677: error: Cannot determine type of "_join_rate_per_room_limiter" [has-type]
synapse/federation/federation_server.py:720: error: Cannot determine type of "_join_rate_per_room_limiter" [has-type]
```
This is #17291 (which got reverted), with some added fixups, and change
so that tests actually pick up the error.
The problem was that we were not calculating any new chain IDs due to a
missing `not` in a condition.
Reduce the replication traffic of device lists, by not sending every
destination that needs to be sent the device list update over
replication. Instead a "hosts to send to have been calculated"
notification over replication, and then federation senders read the
destinations from the DB.
For non federation senders this should heavily reduce the impact of a
user in many large rooms changing a device.
The parse_integer function was previously made to reject negative values by
default in https://github.com/element-hq/synapse/pull/16920, but the
documentation stated otherwise. This fixes the documentation and also:
- Removes explicit negative=False parameters from call sites.
- Brings the negative default of parse_integer_from_args in alignment with
parse_integer.
This reverts commit bdf82efea5 (#17291)
This seems to have stopped persisting auth chains for new events, and so
is causing state res to fall back to the slow methods
We calculate the auth chain links outside of the main persist event
transaction to ensure that we do not block other event sending during
the calculation.
