Add testing of SOCKS proxy, including on ipv6.disable=1 booted systems

[emdee-is]

Turns out there's a lot to testing Tox with Tor. I say with Tor explicity because it's kind of a worse case scenario for a SOCKS5 proxy and it implies some extra gotchas:

1. you want to test on a linux ipv6.disable=1 booted systems and run ctest cleanly
2. you want to test udp disabled, and make sure nothing uses UDP, and that includes DNS leaks on 53.
3. you want to make sure nothing UDP is ever required to boostrap
4. you have to redefine your notion of timeoooooooooooooooooooooouts
5. should your testing reuse a tox profile to cache the peers?

For testing this means adding a Dockerfile test of a qemu machine booted ipv6.disable=1 but also with all of the setup to make apt get in the VM to use Tor. And if you want to use ctest: Tox configures with SOCKS port and host and udp and ipv6 disabled.

And I think this means adding the ip:port for DNS to ToxOptions: in normal tor usage, UDP is firewalled, IPV6 is firewalled and DNS is on port 9053, so Tox must either DNS resolve through tor (like HTTP connect), or add a DNS to ToxOptions.

I'll start by just listing related open issues:
1, An oldie but goldie: #469 which raises the issue of DNS leaks - look carefully at @nurupo comment #469 (comment)
2. The first ever testing of ctest with ipv6=false #2335 using USE_IPV6
3. the ability to test with ipv6=false #2468
6. An equivalent to #2468 is needed for UDP defining USE_UDP_TEST
7. #2469 for SOCKS_HOST_TEST and SOCKS_PORT_TEST
8. A more flexible approach to timeouts: ctest --timeout 1800 does nothing: the test timeout is 120 sec, in CMake

There are some related issues:

1. I raised Still sends IPv6 messages despite the IPv6 options being turned off #1432 in NGC a lot because I thought it shouldn't even be sending ipv6 packets when it was disabled - but got told SNAFU. I don't think I knew that there was an old issue open on it. It used to drive me nuts - went into the code and turned it off, but not recently - or did I turn off toxcore logging in toxygen - maybe that was my answer!? I always compile DEBUG...
2. Beginning with 0.2.4, a lot of errors are printed: attempted to send message with network family 10 (probably IPv6) on IPv4 socket #1026 which I think is stll active.

[emdee-is]

@nurupo can I ask you to elaborate on #469 (comment)

I had a conversation with @irungentoo on IRC about whether we really need to call tox_bootstrap() when having UDP disabled and why.

In practice, does a client with toxoptions ipv6=false local_discovery=false and socks_port and socks_host set ever need to call UDP tox_bootstrap or just tcp_add_relay?

I think I found I had to always call tox_boostrap once - am I wrong to do so? If I'm right is there an obvious way to clean this up?

I note that Tox's proxy test calls tox_bootstrap once even on a tox4 which is udp disabled: https://github.com/TokTok/c-toxcore/blob/master/auto_tests/proxy_test.c#L114

[emdee-is]

In #TokTok @iphydf suggested starting from https://github.com/TokTok/dockerfiles/tree/master/alpine-s390x - in fact, you can probably run alpine-x86_64 with the kernel flags you want, with a copy of those files replacing s390x with amd64 or something (x86_64) https://dl-cdn.alpinelinux.org/alpine/v3.19/releases/x86_64/netboot/ should work. Add ipv6 disable here: https://github.com/TokTok/dockerfiles/blob/master/alpine-s390x/src/setup-vm.expect#L18

... you can build the docker image with the qemu stuff inside, and run that locally
‎ inside the https://github.com/TokTok/dockerfiles repo: docker build -t toxchat/alpine-s390x alpine-s390x

That worked (thanks iphy:), but the Dockerfile now needs to have things changed for apt to be able to update/install under a proxy.

[emdee-is]

The only testing of these things right now is in the integration testsuite for https://git.plastiras.org/emdee/toxygen_wrapper which has the advantage of being Python, so it's more flexible to change all of these options or settings, including timeouts: it doesn't run clean but it's a start. See https://git.plastiras.org/emdee/toxygen_wrapper/src/branch/main/tox_wrapper/tests/tests_wrapper.py

The current ctests almost all run fine even if you're not connected to the internet, with the exception of bootstrap and tcp_relay, so all of the other ctests no not test a real world scenario. The python testrunner tests real world integration scenarios.

[emdee-is]

Over 50000 warning messages of the same kind in one failing test:
https://github.com/TokTok/c-toxcore/actions/runs/7263706761/job/19789612852?pr=2468

[#1] WARNING network.c:946	send_packet:	attempted to send message with network family 10 (probably IPv6) on IPv4 socket

This is what I see on an ipv6.disable=1 system. To that point that my logger callback explicitly looks for these warnings and drops them.

Can you fix the cause of these?