Ignore MisbehavingServers rather than fail with an error

[Ryan Schmidt]

When users who use a broken DNS server [1] try to fetch a port which has one or more master_sites that are offline, they will probably receive an HTML file (from the broken DNS server's search page) instead of the distfile, which will result in a checksum mismatch error followed by this message:

***
The non-matching file appears to be HTML. See this page for possible reasons
for the checksum mismatch:
<https://trac.macports.org/wiki/MisbehavingServers>
***

The user then files a ticket, we must then figure out which of the master_sites is the problem, remove or update its URL, and tell the user to "sudo port clean --all" and try again. It might take us hours or days to notice the ticket and do this. Many tickets of this kind languish because users do not respond to our questions, perhaps because they do not understand the problem; the idea that the .tar.gz file that got downloaded is actually an HTML file that we want the user to open in a text editor is often difficult to convey. Users also seldom seem to have read the MisbehavingServers page. The amount of error message that's spewed at them is considerable, and I don't blame them for not realizing which part we want them to pay attention to, despite our attempts at highlighting it with asterisks. Meanwhile, users who use RFC-compliant DNS servers will simply skip the problem master_site (because their DNS server will simply not resolve the hostname to an IP address) and be able to install the port right away, despite the problem.

The "non-matching file appears to be HTML" message above was the solution that got committed for #25128 [2]. But the fix I originally wrote (see attached patches) worked around the problem, skipping the bad master_site and trying another, matching the experience users with compliant DNS servers would get.

These types of broken DNS servers are obviously not going away and over the years we have received a not insignificant number of tickets as a result. Yes, there is a real problem in either the portfile or the fetch group -- a URL that needs to be removed or updated -- but it's a very minor problem, especially given that we maintain our own network of distfiles mirrors now, and we should not punish users who have broken DNS servers and make them uniquely responsible for shouldering the burden of reporting these problems to us. Instead we should afford them the same convenience users with compliant DNS servers have. Prompted by a recent ticket [3] where this was suggested again, I would like to revisit this issue and commit the fix I originally wrote. Please discuss.


[1] https://trac.macports.org/wiki/MisbehavingServers

[2] https://trac.macports.org/ticket/25128

[3] https://trac.macports.org/ticket/32733