dynamically fallback to getaddrinfo if hickory-dns doesn't work

[NobodyXu]

We could also, dynamically fallback to getaddrinfo if hickory-dns doesn't work
Might be worthwhile to consider, not sure if that has any security concerns (different guarantees? Like with DNSSEC I suppose if someone is expecting a failure to hard-fail)

We could expose this in dns options hickory-dns-with-getaddrinfo fallback so that user can disable it.

Currently we don't provide any guarantee or any option to tune dns, like banning unecrypted DNS or limiting tls version used in dns resolution, so I think it's fine.

Also, we could provide an option to disable hickory-dns at runtime.

That's probably more convenient. You could alternatively publish a build with the feature disabled to releases

Providing builds with features disabled would be more maintenance and most user just use the official one-line script or cargo-binstall to self-update won't notice it.

I prefer disabling it at runtime using cmdline options, that would give them flexibility on this, enabling users to test with a different dns to verify the problem.

Originally posted by @NobodyXu in #1688 (comment)

[NobodyXu]

In the reference thread, for the specific setup inside docker on desktop, using WSL, the getaddrinfo works but hickory-dns does not, possibly due to NSS lookup.

I'd suggest to fallback to getaddrinfo if it doesn't work, it would make cargo-binstall dns resolution works more reliably in these environments.