[PATCH 04 of 10 ipv6 V2] tinyproxy: use IPv6 if HGIPV6 is set to 1

[David Soria Parra]

On Fri, Feb 17, 2017 at 10:51:18AM -0800, Jun Wu wrote:
> # HG changeset patch
> # User Jun Wu <quark at fb.com>
> # Date 1487228025 28800
> #      Wed Feb 15 22:53:45 2017 -0800
> # Node ID c34ad0f0fc375de9e2d96d17ddcb644d9054d154
> # Parent  5e76ef1698fde7a47fa78003beac71324793d051
> # Available At https://bitbucket.org/quark-zju/hg-draft
> #              hg pull https://bitbucket.org/quark-zju/hg-draft -r c34ad0f0fc37
> tinyproxy: use IPv6 if HGIPV6 is set to 1
> 
> This patch makes tinyproxy.py work in IPv6 mode if HGIPV6 is set to 1.
> 
> This will make test-http-proxy.t pass on IPv6 machines.
> 

I might be missing something here as I am a bit rusty on Mercurial
internals, I feel we are not doing the right thing here. I think the
series is not the correct way to approach the issue. When IPv6 and IPv4
is available we should bind to both sockets and have the client doing
proper destination address selection according to rfc6724. According
to the rfc preferring IPv6 over IPv4 should be the default and I feel
introducing a specific switch does not test the correct behavior.

In order to obtain the available localhost addresses we should use
socket.getaddrinfo() to obtain a list of available v4/v6 addresses and
bind on both. This should be doable without using HGIPV6 in tinyproxy
and dumbhttp. We can use this list to glob() 127.0.0.1 correctly, even in the
case of FreeBSD jails and don't rely on hardcoded ::1/127.0.0.1 addresses. This
should allow us to use IPv6 on a test host correctly when avaialble and fallback
to IPv4 graciously. I see why we want to introduce switches in tests for v4/v6
only, but I feel that the current implementation does not correctly test default
addr selection (which might be part of causing the flakeyness).

/D