Permit network-proxy to act between a federation of servers

Nobody has claimed this yet.

Currently network-proxy can sit between a client and a server; it can intercept and block traffic as required for a test. This works by serving a http:// endpoint that can be used by the element web and routes forward to the right place; adjusting well-known responses and so on to keep the client talking to the proxy.

Server-Server logic is harder; we are using complement to setup the servers in a federation; this includes setting up an internal CA and signing certificates for internal trust in the federation.

If we want to intercept this traffic outside of the servers, in the same style as the client interception, we'd need to:
- route traffic to the proxy by running on the correct host, or by faking a well-known response to route traffic to the proxy
- make a fake TLS cert to act as the server
- make sure the servers know when to use the fake proxy and when not to.

This is hard, so a different model for the server-server comms might be needed, by embedding the proxy before the server we can avoid interfering with the existing TLS cert and network routing, and make it available to all servers.

I propose:
- in the docker image (probably a new one based on the existing one) we should adjust the docker image run by complement to include the network proxy codebase
- in the startup script we should use the complement feature to pass env vars into the container to set, eg: `COMPLEMENT_SHARE_ENV_PREFIX=PASS_ PASS_TRAFFICLIGHT_SERVER_URL=http://trafficlight/` so the network proxy can receive a parameter to find trafficlight
- in network-proxy we should add the ability to report back to TL the server name that was started as part of the initial registration of the network-proxy
- in TL should use this to match the network-proxy client to the test in question, `await`ing the registration before allowing the test to begin
- in TL the HomeServer class should have all the properties of the NetworkProxy class - so it can be blocked/unblocked
- in TL there should be no need to do the inital proxyTo command - we can hardcode the proxy for a server to be routing internally.

This is quite a few changes that need to happen but the overall path is fairly simple using already existing / understood mechanisms.

Start by tracing the Complement Docker image and startup script, then inspect the network-proxy and TL HomeServer/NetworkProxy integration points mentioned in the proposal. Map how env vars, proxy registration, and proxyTo currently work. Done means federated servers can register with the correct test, be blocked or unblocked, and route internally without the initial proxyTo command.

Written by the indexing model from the issue text.