Gracefully handle socket creation failure

[tjstum]

It is possible that the call to create a regular socket fails, even
before you try to do anything with it. In those cases, we should allow
another attempt to succeed.

One way that this can happen is on linux with ipv6.disable=1 on the
kernel command line. In this case, opening a socket with an IPv6
address family will fail with EAFNOSUPPORT.

[tjstum]

I'm happy to add a test for this if you can give me some guidance about how you'd like to simulate such an error (I could monkeypatch socket.socket, but that may be controversial)

[agronholm]

What's wrong about using monkey patching in tests?

[tjstum]

Nothing! I just wanted to make sure that was an approach you'd endorse. I'll update the branch to include a test later.

I'm also unsure about the CI checks there. It seems that the CI doesn't run against master? The badge on README suggests that they're not running, and the only builds on the Azure Pipeline page seems to be mine. I'm not sure I understand how this change would cause the test failures reported there. I can dig further later today, but I figured I'd ask if there's some known issue.

[agronholm]

git checkout --progress --force refs/remotes/pull/83/merge <- this is what it does, should be right, yes?

[agronholm]

The previous builds seem to have gone – no idea where to.

[agronholm]

The tests would be very welcome. If you can prove that this patch actually fixes something, I will merge it right away.

The failure of the test suite is due to some change in trio 0.13. It passes fine on 0.12.1.

[tjstum]

Yeah, I do plan to add the tests. I just haven't had a moment to do it yet.

What do you want me to do regarding the CI failure, if anything?

[agronholm]

What do you want me to do regarding the CI failure, if anything?

If you look at the CI status now, you can see that it's passing because I fixed the problems (introduced by trio 0.13) and updated this PR to match.

[agronholm]

I couldn't wait any longer so I just made my own patch and tests. Thanks for the heads up though.

[tjstum]

Thanks! Sorry for the delay. It's just been a busy week for me.

I might still have a go at adding tests that simulate the exact issue I had (which is basically limited just to sockets created with AF_INET6 on linux kernels that have ipv6 globally disabled) if you're interested.

[agronholm]

I might still have a go at adding tests that simulate the exact issue I had (which is basically limited just to sockets created with AF_INET6 on linux kernels that have ipv6 globally disabled) if you're interested.

Nah, the test I added covers that case just fine.