Torsf measurements are unusable

[PoleTransformer]

Describe the bug

Thousands of anomalies even in uncensored countries where Tor snowflake is expected to work. https://explorer.ooni.org/chart/mat?since=2024-07-08&until=2024-08-08&time_grain=day&axis_x=measurement_start_day&test_name=torsf

Started on September 20, 2023 because the domain front cdn.sstatic.net switched to Cloudflare: https://forum.torproject.org/t/problems-with-snowflake-since-2023-09-20-broker-failure-unexpected-error-no-answer/9346

And this matches with the MAT data as well, anomalies starting on the 20th: https://explorer.ooni.org/chart/mat?since=2023-09-19&until=2024-08-08&time_grain=day&axis_x=measurement_start_day&test_name=torsfSignificantly worse than https://github.com/ooni/probe/issues/2063

Since the domain fronts are hard coded, any changes to hosting breaks these measurements. A lot of CDNs are blocking domain fronting, which means we need to update the domains without relying on updates to the engine. https://github.com/ooni/probe/issues/2063

System information (if applicable):

Affects version of ooni-cli <= v3.20.1.

Potential Solutions

We can fetch the latest default bridges from the Tor project gitlab: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/raw/main/projects/tor-expert-bundle/pt_config.json and parse out the domains. This way upstream changes can be reflected in the tests. If that fails, fallback on hard coded domain fronts.

Many CDNs return an error when domain fronting is blocked such as http 451. We can test if domain fronting works by using curl and looking at the http response from the server. If its not http 200, exit immediately, else continue test.

Prevent submission of torsf measurements from old versions of ooni probe <= v3.20.1. A server check that can't be overwritten by an environment variable.

Allow user to overwrite the domain front and broker domain. Not going to be super practical because a lot of users simply set and forget.