Fix/Implement own DNS resolver

[jhass]

The current DNS resolver is broken for some usecases, buggy for others and some setups. We should replace it. See #2568 #2653 #2426.

A resolver written in Crystal is tricky since it would need to hook into OS specific APIs in order to resolve hosts from /etc/hosts, mDNS etc. Most POSIX API is blocking making it tricky to rely on in a language focused on asynchronous IO, see #2426 (comment)

This issue exists to collect issues in the current implementation and ways to mitigate them in possible replacements.

[lbguilherme]

A possible implementation route would be using a library such as https://c-ares.haxx.se/ instead of creating it from scratch. This one seems to be portable across POSIX and Windows and can integrate with libevent. For example:

The ares_fds function retrieves the set of file descriptors which the calling application should select on for reading and writing for the processing of name service queries pending on the name service channel identified by channel.

From a very quick search, there are other libraries with similar functionality.

[asterite]

I propose to use C's getaddrinfo until we solve this well in a non-blocking fashion. I think it's preferable to have a blocking thing that works well than a non-blocking thing that's broken (and sometimes in a subtle way). Yes, sometimes a program will have hiccups of up to 5 seconds, but it will eventually work well.

We'd have to revert this commit and a maybe some others.

[zamith]

At this point with Crystal 0.17.4 I cannot use http/client because of this. Is it something related to my system, or is it broken?

[ysbaddaden]

Closing: this should have been fixed by #2745.

[Sija]

@ysbaddaden But was it? If so, why #6099 then?

[rdp]

For followers, appears #6099 was caused by a shared v. static linking issue...FWIW...see also #4816