Occasionally we could get a federation device list update transaction which
looked like:

```
[
    {'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D2', 'prev_id': [], 'stream_id': 12, 'deleted': True}},
    {'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D1', 'prev_id': [12], 'stream_id': 11, 'deleted': True}},
    {'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D3', 'prev_id': [11], 'stream_id': 13, 'deleted': True}}
]
```

Having `stream_ids` which are lower than `prev_ids` looks odd. It might work
(I'm not actually sure), but in any case it doesn't seem like a reasonable
thing to expect other implementations to support.

make sure we clear out all but one update for the user

this is never set to anything other than "test", and is a source of unnecessary
boilerplate.

Ensure good comprehension hygiene using flake8-comprehensions.

... and use it in places where it's trivial to do so.

This will make it easier to pass room versions into the FrozenEvent
constructors.

Ensure that the the default settings for the room directory are that the it is hidden from public view by default. 

Rate-limit outgoing read-receipts as per #4730.

... as described at
https://docs.google.com/document/d/1EttUVzjc2DWe2ciw4XPtNpUpIl9lWXGEsy2ewDS7rtw.

setup_test_homeserver function in utils.

Supply auth_chain along with current state in '/state/', fetch auth events from a remote server if we are missing some of them

SYN-103: Ignore the 'origin' key in received EDUs. Instead take the origin from the transaction itself

Add a keyword argument to get_json to avoid retrying on DNS failures. Rather than passing MatrixHttpClient.RETRY_DNS_LOOKUP_FAILURES as a fake query string parameter