DNS client improvements (UDP & resolv.conf parsing & multiple name servers)

[hannesm]

This is copied from the discussion with @cfcs in #241 and scheduled for the next major release

To iteratively move forward, my suggestion is (where the checkboxes are intended for the next release, (later) for some future release):

• together with mirage: dual stack (Mirage_stack.V4V6) support #239 we're breaking the API anyways, let's have create receive a nameserver list
• work on enhancing the resolv-conf parser (timeout, ..) and the DNS client semantics (remember which NS was tried last, ...)
• get UDP support in the client(s) -- we can retain TCP as default (eventually with caching the TCP connection, as done in dns-stub), but mainly need retransmission (on lookup timeout)
• domain / search support for resolv.conf
• keep a hash of the resolv.conf contents, and on lookup failure re-read that file (to support laptops who joined a different network, and resolv.conf was updated by DHCP etc.) dns-client: if /etc/resolv.conf modifies, update the internal list of resolvers #291
• (later) add DNSSec validation (needed for a reasonable recursive resolver anyways - need some magic to have it disabled when in a network where you've to browse somewhere and click ok)
• add DNS-over-TLS support (here question arise in the form of "where does the certificate come from" etc.)

[hannesm]

With #269 there are some fixes: now all nameservers from /etc/resolv.conf are used. Also, the lwt DNS client uses UDP and TCP (the unix one as well, but only the first nameserver).

I don't think that with DNS-over-TLS on the horizon we should strive for UDP support in the MirageOS DNS client. Instead I'd be in favour to allow TLS and TCP only (and maybe remove UDP support from the Lwt_unix and Unix clients as well). Reasoning is less code and more reliability.

[hannesm]

Closing this issue, as most tasks have been accomplished. The remaining "support for search in /etc/resolv.conf" can be done once someone reports the demand for it.