Project put on hold when there are connectivity issues with LD

[josephmyers]

Today, the internet has been quite upset with me. Specifically, languagedepot.org operations seem to be taking longer than normal or failing outright until rerun. The problem is that LfMerge doesn't handle connectivity problems well. If it's not able to "receive from Language Depot" for whatever reason, it will lock up the project by putting it on hold. This seems like overkill. Why not allow them to retry? Here's the log:
log.txt

Interesting to note that it does say "Connection refused" -- seems more a timeout than a refusal. If it is being actively refused, putting things on hold could be intended, but it will certainly inconvenience the project (easier than most DoS attacks). If it's a connection issue, we shouldn't be locking everything down for something that could easily resolve itself on the next try.

Interestingly, here's a snippet from the log for a successful S/R: log2.txt
Navigating to this https://hg-public.languagedepot.org/ site in browser every once in a while gives me an internal server error; the other times it requests a user/pass.

I haven't seen this on QA -- just seeing it right now with local as admin. If we're only seeing this locally, maybe it's not an issue.

[megahirt]

Connectivity between these two should not be an issue in production, as both LD and LF are VMs in the same Amazon data center.