Additional tests for device list updates

It is possible for homeservers to miss device list updates. This means the local copy of a device list for a remote user can become stale, or out of sync with their actual device list, because further updates will be deltas with the previously sent ones.

To ensure inbound device list updates are reliably implemented in a HS implementation, we should test that:

* Upon receiving a new device list updates which prev ID is unknown, the HS queries [`/_matrix/federation/v1/user/devices/{userId}`](https://matrix.org/docs/spec/server_server/unstable#get-matrix-federation-v1-user-devices-userid) (spec says otherwise, but see https://github.com/matrix-org/matrix-doc/issues/2710) on the remote HS
* If the remote HS is down, this request is retried in a timely manner; this is not in the spec because the spec doesn't mention any way of making device list updates reliable, but this is how we do it in Synapse and the simplest way to implement some level of reliability here imho so it might be something we should at least nudge implementations into doing through sytest
* Cross-signing keys are correctly processed from the response to this request (as per https://github.com/matrix-org/matrix-doc/pull/2536)
* Homeservers can process device list updates that come in out of order (i.e. not sorted on their stream ID in the federation transaction)

The second point is difficult to test, though, because we don't currently have a way to test things like retry schedules.

Start by reviewing Sytest's existing coverage for inbound device-list updates and the Matrix federation user-devices endpoint named in the issue. Add coverage for unknown previous IDs, cross-signing keys, and out-of-order updates; confirm with maintainers how the retry behavior should be represented, since the issue notes that retry schedules are not currently testable.

Written by the indexing model from the issue text.