Name server requests can fail due to reliance on "services" file

Before sending a request to a name server, we first need to resolve the server's URL (default: https://ns.jami.net) into a list of TCP endpoints (IP address + port number). This is currently done in the NameDirectory constructor via OpenDHT's Resolver class. The Resolver constructor splits the server URL into a host name and service (ns.jami.net and https respectively for the default URL), which are later passed as arguments to Asio's ip::tcp::resolver::async_resolve function.

In order to resolve a service name into a port number, async_resolve may rely on the contents of system files such as /etc/services on Linux or c:\windows\system32\drivers\etc\services on Windows. A file that's inaccessible or corrupted can therefore cause service resolution to fail (this shouldn't happen often, but we have seen it occur in practice -- in particular, on Windows systems that had been cloned from another system, and on which the c:\windows\system32\drivers\etc\services could not be read/open due to what was presumably an error during the cloning process).

If async_resolve fails, then all subsequent name and address lookups will fail and return an HTTP status code 0:

[1744644530.517|35566|namedirectory.cpp       :273 ] Name lookup for a on https://ns.jami.net failed with code=0
[1744644531.562|35538|namedirectory.cpp       :273 ] Name lookup for al on https://ns.jami.net failed with code=0
[1744644532.130|35538|namedirectory.cpp       :273 ] Name lookup for ali on https://ns.jami.net failed with code=0
[1744644533.660|35538|namedirectory.cpp       :273 ] Name lookup for alice on https://ns.jami.net failed with code=0
[...]
[1744644567.350|35563|namedirectory.cpp       :197 ] Address lookup for 777fef0a900b5e4e5c042a3374c776f1c3f26ac1 on https://ns.jami.net failed with code=0

A workaround for this issue is to manually specify a port number (this can be done by going to the "Advanced settings" in Jami and enter ns.jami.net:443 as the name server address). However, this should really be fixed at the level of OpenDHT.