`/_matrix/client/v1/rooms/{roomID}/hierarchy` hangs on dead `via` in `m.space.child`

*This issue was originally created by [**@swedgwood**](https://github.com/swedgwood) at .*

Present in latest release (v0.13.1) and main as of submission (294eff8a7f42f11b3559ca941468c766358fcae1)

When doing federated requests for room hierarchies, we wait a full 1 minute timeout (see [`federationapi/internal/federationclient.go`](https://github.com/matrix-org/dendrite/blob/294eff8a7f42f11b3559ca941468c766358fcae1/federationapi/internal/federationclient.go#L200)), and we also do all the requests sequentially (not parallelised).

This means is an old space has rooms with lots of dead `via`s, the request can very quickly get multiple minutes in length (which usually times out).

A temporary solution might be to just shorten the timeout, but this will still add up in bigger spaces, so it may be worth parallelising the federated queries as well as shortening the timeout.

### Repro

1. Have two servers with two users, here (`@alice:hs1` and `@bob:hs2`, hs2 must be dendrite, hs1 can be anything)
2. Create a space using `@alice:hs1`, adding some rooms
3. Edit the `m.space.child` events to change the `via` field to a dead server, but this has to be a server that doesn't immediately refuse the connection (e.g. I pointed `dead.server` to `1.1.1.1` in the `/etc/hosts` of `hs2` and used that as the server name)
4. Invite `@bob:hs2` to the space, and query the room hierarchy (e.g. on element, going to the space home)
- when their homeserver generates the space summary, it will not be aware of the rooms inside, and so make federated queries to the server names in `via` - which it will then hang on
5. Observe that `@bob:hs2`'s room hierarchy takes a long time to generate