Update happy eyeballs for RFC 8305

[njsmith]

A new happy eyeballs RFC came out a few months ago: https://tools.ietf.org/html/rfc8305

Golang tracking issue: golang/go#23841

It's interesting. The old one (RFC 6555) was incredibly vague; lots of "well maybe you could do this, or maybe that, there are lots of options ok", then with a paragraph stuck in at the end claiming (incorrectly) to document what browsers actually do. This one has actual concrete recommendations, and apparently corresponds to what MacOS/iOS do. So... anything we should take from it?

They recommend a 250 ms default timeout. Okay, sure, cool. There's some language about adjusting this based on history, within the bounds of 100 ms and 2 s, but I don't think we want to bother tracking history. And, we're not in a great place to do it either – if we were in the kernel or glibc then it would make more sense.

They recommend doing some cleverness with AAAA vs A records during DNS lookup, where if you get a DNS response for your preferred address family first, you should go ahead and start making connections while waiting for the other DNS response. It turns out that you actually can use getaddrinfo to do separate AAAA and A lookups (just specify family=AF_INET6 vs family=AF_INET; in glibc at least this does correctly trigger the appropriate DNS queries, confirmed with wireshark). So in principle we could implement this pretty easily... IF we knew the local host's policy for preferring IPv4 vs IPv6. Which we don't, since it's some operating system level tuning parameter and there's no standard API for accessing it. Sigh. Maybe the new RFC will encourage OSes to implement better APIs here? There's some temptation to hard-code a preference for AAAA, because c'mon it's the future, and that might work fine on consumer devices, but I think this might annoy all the folks still using IPv4-only networks in the datacenter, and that's kind of an important target userbase for trio.

In fact a lot of the fancier recommendations really only make sense when the happy eyeballs algorithm is integrated into the OS. Does anyone know how Apple actually exposes their implementation? Is there some API we should be calling on macOS instead of using our implementation? Or do you have to switch over to some totally different networking API instead of BSD sockets?

It looks like in the short term the only action item here might be to switch our default delay to 250 ms. (I'm sort of tempted to refactor our happy eyeballs implementation a bit while I'm in there, to more closely match the later version I use in the talk, and to track unclosed sockets in a more automated way.)

[joernheissler]

On my system the default is to return v6 addresses first, then v4. This can be changed in /etc/gai.conf.
When I remove my v6 default route, getaddrinfo will return the v4 address first.

I think you should let getaddrinfo just do what it does.

[njsmith]

@joernheissler Yeah, that's what I mean when I complain that we can't do anything clever with DNS lookups because we have no reliable way to figure out whether the OS is configured to prefer IPv4 or IPv6.

[njsmith]

The "good first issue" part is: Changing the default timeout in trio.open_tcp_stream to be 0.250 seconds instead of 0.300 seconds