Handle peers that accept connections but close immediately

Some peers will accept a connection then close. They may or may not send an introduction message. It may be that this peer does not accept our introduction message.

Detect and handle the case where the peer repeatedly connects then fails with a read EOF error.

Probably it could be assumed that if we have a read EOF error after connecting and maybe receiving an INTR packet but no other packet, then this is a bad connect. Increase some bad connect counter (not necessarily the same as the RetryTimes counter, which is used for exponential backoff). Once this hits some threshold, remove it from the peerlist. Alternatively, the problem may sort itself well enough using exponential backoff alone (eventually connection attempts to a bad peer would be so infrequent to not notice).

Exponential backoff issue: #1989