feat: add echcheck to the experimental suite

[kelmenhorst]

Checklist

• I have read the contribution guidelines
• reference issue for this pull request: add probe for TLSv1.3 ECH (Encrypted ClientHello, ESNI replacement) probe#1453 cli: add echcheck to the experimental suite probe#2547
• if you changed anything related to how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/kelmenhorst/spec/tree/echcheck-spec
• if you changed code inside an experiment, make sure you bump its version number

Description

This diff does two things:

1. Add echcheck to the experimental nettest suite. We do not provide input which causes the experiment to use the default URL https://crypto.cloudflare.com/cdn-cgi/trace (URL proposed by @eighthave). With this single input configuration we can collect the first experimental ECH measurements.
2. Add netem tests to echcheck, while keeping a "real-internet" test to connect to an ECH-enabled server.

[eighthave]

I don't know this codebase, or Go for that matter, so I can't really follow this. But the idea sounds good. I would recommend including the data that https://crypto.cloudflare.com/cdn-cgi/trace returns, especially the results of the sni= field. For example:

fl=125f76
h=crypto.cloudflare.com
ip=23.153.248.38
ts=1693413463.195
visit_scheme=https
uag=Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
colo=MCI
sliver=none
http=http/2
loc=T1
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519

You can see my Firefox does not have ECH enabled, since sni=plaintext

[kelmenhorst]

@eighthave Yes I was thinking the same. However, at the moment, echcheck only handshakes. That said, I don't see a reason why we should not do HTTP GET here.

[bassosimone]

@kelmenhorst the reason why we should not fetch the webpage here was that the result included the IP address of the probe and we would like to avoid that. We used to have a mitigation where we scrubbed the IP address known to us, i.e., the one we discovered, from the measurement result. Since v3.19.0-alpha, there's now a much more robust mitigation where we scrub any IP address or endpoint, which means now it is much safer to fetch this page.

To clarify: we discover one of the probe's IPv4 and IPv6 addresses and tend to prefer IPv4 during DNS lookups, so the previous scrubbing policy has been fine in 99% of the cases. The new policy ensures we cover all possible cases.

[bassosimone]

🐳