Make 'adcli info' DC location mechanism more compliant with [MS-ADTS] and [MS-NRPC]

AD specifications say that DC locator must attempt to find a suitable DC for the client. That means going through all of the DCs in SRV RRs one by one until one of them answers.

The problem with adcli's original behavior is that it queries only five DCs from SRV, ever. This becomes a problem if for any reason there is a large number of DCs in the domain from which the client cannot get a CLDAP response.

The link in the comment references documentation from 2014 that's technically deprecated, though packet captures of Windows 10 1809 show that behavior is still unchanged. Reading through the original doc more closely, the timeouts of 0.4, 0.2, and 0.1 seconds are specific to Windows client implementation, and I was unable to find specific NetLogon ping timeout mandates in any of the non-deprecated documentation. Nevertheless, I'm inclined to mimick Windows implementation, because even in case of domain with a mere 120 DCs (with limit of 1200 DCs per domain) the timeout of 0.1 seconds in this patch results in possibility that pinging all of the DCs will take more than 12 seconds, and in case of maximum number of DCs it can take more than two minutes; setting initial timeout to anything less may be a) impractical for high latency networks and b) may result in client spamming network with unnecessary UDP packets, setting it to anything more may result in a very long time before 'adcli info' returns any results for a big domain in the original scenario described (clients are isolated from non-site-specific DCs).

This merge request is expected to close the issue #13 (closed)