richer input: riseupvpn as a use case

[bassosimone]

This issue is related to ooni/probe-cli#1125 and explores how it would look like to redesign the RiseupVPN experiment using the richer input (and, specifically, the DSL introduced in ooni/2023-05-richer-input#7. RiseupVPN is an interesting use case because this experiment is developed in collaboration with Riseup developers such as @cyBerta. We will consider this issue done when we'll have sketched out how RiseupVPN could look like when using richer input and we have gathered feedback on the strawman design. (This work goes hand in hand with the review of ooni/probe-cli#1125 and informs some of the cherry-picking choices we may apply in this respect.)

[bassosimone]

Okay, I have implemented it and merged the implementation. Here's how it works:

1. The backend periodically runs pkg/x/cmd/riseupvpn, which calls the proper bootstrap APIs and generates a DSL including both the API targets and the gateway targets;

2. The backend will serve to ooniprobes the DSL defining how to run riseupvpn nettests. Possibly, the probe would cache this information for some time (a week?) to allow for running backend-less measurements for some time.

3. The probe runs the experiment by interpreting the DSL.

As I am going to argue in ooni/probe-cli#1125, the implementation I wrote here does not write toplevel test keys.

Note that riseupvpn is the perfect candidate nettest to be upgrade to the DSL because it is currently disabled out of false positive concerns. My rough plan to move forward is the following:

1. stop creating toplevel keys such that we focus on collecting data and reckon with the fact that we cannot reliably flag riseupvpn directly in the probe (the implementation in https://github.com/ooni/2023-05-richer-input already does not have toplevel keys, so we've already done this step);

2. have the check-in v1 API serve us the DSL for riseupvpn (remember that the check-in v1 API response is compressed and note that the DSL compresses quite nicely);

3. import into probe-cli the dsl package and write the missing unit tests;

4. rewrite the riseupvpn experiment to use the DSL by copying from the prototype repository https://github.com/ooni/2023-05-richer-input;

5. write additional netem based tests if needed;

6. teach the probe to cache the riseupvpn DSL on the local key-value store;

7. the experiment implementation proper will read the DSL from the local key-value store and then interpret the DSL.

I think it should be possible to include this revamped riseupvpn in v3.19.0.

To conclude: because I was able to write a complete prototype, I think we can consider this activity done.