Calculate the blocking key needed by OONI Explorer measurement pages

[hellais]

The web_connectivity measurement details page of OONI Explorer uses the test_keys->blocking key of the raw measurements (which is calculated on the probe) that can be mis-aligned with what the fastpath believes to be the blocking reason.

We should re-compute the blocking reason in the fastpath and serve it to OONI Explorer.

This issue superseeds: ooni/explorer#360

[azadi]

I am not sure if this is related but I will hopefully try to be useful:

The snippet below is from running a query on metadb:

   test_start_time   | measurement_start_time |              measurement_id               | m_report_no | anomaly | confirmed | coalesce_2 |                                                            scores                                                            | exc | residual_no |                                  report_id                                  | probe_cc | probe_asn |    test_name     |           input           
---------------------+------------------------+-------------------------------------------+-------------+---------+-----------+------------+------------------------------------------------------------------------------------------------------------------------------+-----+-------------+-----------------------------------------------------------------------------+----------+-----------+------------------+---------------------------
 2020-02-02 20:49:59 | 2020-02-02 20:49:59    | temp-fid-00d4fe139c14b9c6a86e3d5a0f6e16ff |    12411773 | f       | f         | f          | {"blocking_general":0.0,"blocking_global":0.0,"blocking_country":0.0,"blocking_isp":0.0,"blocking_local":0.0,"accuracy":0.0} | {0} |     1716728 | 20200202T204924Z_AS56402_FFVjCWvZqfWrhAZgXuJahKRGZjikgmUyJ5zerNdcuXmdepZHVo | IR       |     56402 | web_connectivity | https://ca.wikipedia.org/

But if you see the measurement on OONI Explorer (https://explorer.ooni.org/measurement/20200202T204924Z_AS56402_FFVjCWvZqfWrhAZgXuJahKRGZjikgmUyJ5zerNdcuXmdepZHVo?input=https%3A//ca.wikipedia.org/), it says that this is an anomaly and rightfully so.

Anyway, just thought I should share in case this was related.

[hellais]

@FedericoCeratto can you check if this is currently done?

[hellais]

This is now possible thanks to the metrics from the new pipeline. In order for it to work effectively we probably have to reduce the frequency of the runs of the new pipeline and possible plug it in to process data in realtime.

See: ooni/data#111