s3-dsgetdcname: handle num_ips == 0

This is a WIP fix for a crash in net ads join caused by failed DNS address lookup or other corner cases...

The real fix is that ads_dns_query_srv() should hide this properly.

ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==10771== Invalid read of size 16
==10771==    at 0x6FD33ED: sockaddr_storage_to_samba_sockaddr (util_net.c:1081)
==10771==    by 0x812F962: discover_dc_dns (dsgetdcname.c:604)
==10771==    by 0x81310A2: dsgetdcname_rediscover (dsgetdcname.c:1028)
==10771==    by 0x81310A2: dsgetdcname_internal (dsgetdcname.c:1126)
==10771==    by 0x81303F9: dsgetdcname (dsgetdcname.c:1182)
==10771==    by 0x8AE371E: libnet_DomainJoin (libnet_join.c:2628)
==10771==    by 0x8AE371E: libnet_Join (libnet_join.c:2837)
==10771==    by 0x13F709: net_ads_join (net_ads.c:1966)
==10771==    by 0x1824B7: net_run_function (net_util.c:587)
==10771==    by 0x14755D: net_ads (net_ads.c:4070)
==10771==    by 0x1824B7: net_run_function (net_util.c:587)
==10771==    by 0x13DC4F: main (net.c:1422)
==10771==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10771==
==10771==
==10771== Process terminating with default action of signal 11 (SIGSEGV): dumping
core
==10771==  Access not within mapped region at address 0x0
==10771==    at 0x6FD33ED: sockaddr_storage_to_samba_sockaddr (util_net.c:1081)
==10771==    by 0x812F962: discover_dc_dns (dsgetdcname.c:604)
==10771==    by 0x81310A2: dsgetdcname_rediscover (dsgetdcname.c:1028)
==10771==    by 0x81310A2: dsgetdcname_internal (dsgetdcname.c:1126)
==10771==    by 0x81303F9: dsgetdcname (dsgetdcname.c:1182)
==10771==    by 0x8AE371E: libnet_DomainJoin (libnet_join.c:2628)
==10771==    by 0x8AE371E: libnet_Join (libnet_join.c:2837)
==10771==    by 0x13F709: net_ads_join (net_ads.c:1966)
==10771==    by 0x1824B7: net_run_function (net_util.c:587)
==10771==    by 0x14755D: net_ads (net_ads.c:4070)
==10771==    by 0x1824B7: net_run_function (net_util.c:587)
==10771==    by 0x13DC4F: main (net.c:1422)
==10771==  If you believe this happened as a result of a stack
==10771==  overflow in your program's main thread (unlikely but
==10771==  possible), you can try to increase the size of the
==10771==  main thread stack using the --main-stacksize= flag.
==10771==  The main thread stack size used in this run was 8388608.