check-in v1: richer input for riseupvpn: discuss protoype

[bassosimone]

Similar to #754, but for riseupvn. The main task here is not necessarily implementing and merging, rather discussing a prototype implementation and decide whether it would make sense to merge or whether it could tie our hands for the future. More specifically, consider the following:

1. a minimal implementation of richer input for riseupvpn would just deliver the correct CA to probes (similarly to what we plan on doing for signal);

2. probably we're going to be fine if we react to CA issues and update the CA (like we're doing for signal);

3. however, it may be worth discussing also invoking the riseupvpn API to obtain endpoints to measure (which is more radical than just serving the correct CA but significantly contribute to make the experiment more dynamic);

4. if we do that, we would probably need to have some service in the backend periodically calling riseup APIs.

My inclination is to split the work into two activities. The first activity is about just adding the correct-CA support and the second activity is about adding support for gathering endpoints. I'd like to discuss this plan with @ooni/ooni-team.

[bassosimone]

As discussed in ooni/probe-cli#1621 and considering previous conversations with Arturo and given the work he's been doing to divide the backend in tiers, it's not critical anymore to discuss a prototype and we can just follow the new pattern of having a microservice for serving this kind of richer input (or a pool of related inputs that are all deemed not P0) without the need to have extensive discussions. Yay for the tier architecture!