Experimental Tor/SOCKS5 support for req/resp protocols

[oskarth]

Problem

For request/reply protocols used by restricted nodes (https://rfc.vac.dev/spec/30/) such as lightpush (connectivity), filter (bandwidth), store (uptime), there are currently few metadata protection guarantees.

Suggested sketch

Enable SOCKS5 proxy support https://github.com/status-im/nim-libp2p/issues/358, then do a PoC using e.g. store protocol for hardcoded/discovered onion address.

Why

Doing this would provide better metadata protection for lighter nodes using e.g. desktop. It'd also give users flexibility, give more credibility in terms of working with other projects and not just doing our own thing, and will give us.

It'll also be a stepping stone towards better understanding of privacy guarantees Waku should focus on, making the Waku use case and story even more clear in terms of how it compares with / complements Tor, etc.

Also see

• SOCKS proxy support https://github.com/status-im/nim-libp2p/issues/358

-OpenBazaar go-onion-transport https://github.com/OpenBazaar/go-onion-transport

• Berty libp2p transport https://github.com/berty/go-libp2p-tor-transport

• Waku vs Tor (focused on relay portion of network) https://github.com/vacp2p/research/issues/85 and https://github.com/vacp2p/research/issues/86 and https://github.com/vacp2p/research/issues/87

• Secure messaging comparison https://oaklandsok.github.io/papers/unger2014.pdf

• (Some other libp2p onion transport thing gpestano did that I can't find now)

Acceptance criteria

• PoC of using SOCKS5 and onion addresses for req/resp protocol
• Spec update showing this is possible -- should also show tradeoffs here (daemon, discovery, latency)
• Further issues cut out for improvements -- tie into Waku vs Tor comparison [similarities and differences - pros and cons], Discovery tweaks (e.g. Disc v5 UDP based), libp2p/Ethereum upstream, etc

[Menduist]

Tor support as been merged in libp2p: https://github.com/status-im/nim-libp2p/pull/765