This is because getcallargs recomputes the getargspec, amongst other
things, which we don't need to do as its already been done

The cache wrappers had a habit of leaking the logcontext into the reactor while
the lookup function was running, and then not restoring it correctly when the
lookup function had completed. It's all the fault of
`preserve_context_over_{fn,deferred}` which are basically a bit broken.

Fix bug where current_state_events renamed to current_state_ids

* Bail early if remote wouldn't be retried

* Don't always return true

* Just use get_retry_limiter

* Spelling

Don't user upsert to persist new one time keys

Notify on new federation traffic

Fix installation issues

Batch sending of device list pokes

Short circuit if all new events have same state group

Use presence replication stream to invalidate cache

Add slave transaction store to workers who send federation requests

Instead of using the cache invalidation replication stream to invalidate
the _get_presence_cache, we can instead rely on the presence replication
stream. This reduces the amount of replication traffic considerably.

Cache hosts in room

try not to drop context after federation requests

Add another missing yield on check_device_registered

Reduce some CPU work on DB threads

cursor_to_dict can be surprisinglh expensive for large result sets, so lets
only call it when we need to.

Fix token request for addition of phone numbers

Fix rejection of invites not reaching sync

preserve_context_over_fn uses a ContextPreservingDeferred, which only restores
context for the duration of its callbacks, which isn't really correct, and
means that subsequent operations in the same request can end up without their
logcontexts.

push federation retry limiter down to matrixfederationclient

Fix time_bound_deferred to throw the right exception