Deploy the PT reachability tests on some centralised system which reports to BridgeDB/BridgeAuth
We need PT reachability tests for all bridges once #7349 (moved) is complete, or much preferably before.
I propose we deploy the solution from #6396 (moved) on some new, separate machine which reports to BridgeDB or the BridgeAuth.
For reporting purposes, I also propose we define a better (e.g. more future-proof) system for specifying which PT instance we are talking about for which bridge. In general, it should be capable of handling:
- Both RSA and Ed25519 relay identity fingerprints/keys,
- Multiple instances of the same PT (#11211 (moved)),
- Specifying which transport is/was/should be running
Basically, I expect this to (nearly?) be the full PT bridge line. Should it include PT args? E.g. the cert= field for obfs4? (Perhaps it would be simplest to just define it as the full bridge line that BridgeDB would give out, to reduce code duplication and parsing.)
I also propose that the set of PTs which are used to test are the same PTs which are, by default, bundled in Tor Browser. (Should we use the set from alpha or stable?) E.g. if your bridge is only running the snarggleblarf PT and has no ORPort, and TB doesn't know what the snarggleblarf PT is, then for the purposes of the test, we've no idea if your bridge is Running or not.
Lastly, what does it mean if a bridge without an ORPort, and running obfs3, fte, and obfs4, is found to only be reachable via obfs4? Does this bridge still get the Running flag from the BridgeAuth? Should there be some per-bridge-line Running flag? If this data is reported to the BridgeAuth, how will the BridgeAuth communicate it to BridgeDB (so that BridgeDB knows what to hand out)?
Related: #5211 (moved), #13589 (moved)