Implement behavior for #152 disconnect package "banned"

[kilrau]

This is an offshoot of #152 and #616 to implement the following behavior for the 'special' disconnect packet "banned"

• if we're getting the p2p packet: disconnecting #152 packet for being banned instead of HELLO on connection attempt, socket gets closed by peer and we should stop connecting to the peer (ban/disable outgoing connections to this node). TBD: persistent or in-memory only? If peer successfully connects to us again, we delete the entry. Kilian: I'd vouch for a new db field as @sangaman suggested below (Implement behavior for #152 disconnect package "banned" #693 (comment)).
• if peer doesn't send p2p packet: disconnecting #152 or HELLO packet on connection attempt but any other non-recognized packet, cancel and don't attempt to reconnect (peer doesn't follow the protocol) (ban/disable outgoing connections to this node). TBD: persistent or in-memory only? If peer successfully connects to us again, we delete the entry. Kilian: I'd vouch for a new db field as @sangaman suggested below (Implement behavior for #152 disconnect package "banned" #693 (comment)).
• If peer doesn't send any packet, try reconnecting as per Connection retry logic of an momentarily unavailable peer #311

[sangaman]

If we dont get any response when connecting to a peer (2nd bullet point), I think it makes to sense to keep retrying as we do currently. It could be due to a transient system or network issue.

If we get a disconnecting packet that tells us we are banned, we should stop trying to reconnect, and I think probably update the node instance in the database to not attempt to reconnect on restart (new db field would probably be needed).

If we get a disconnecting packet but it is also something transient, I figure we should keep retrying the connection as we do currently.

[kilrau]

Revised description, was not clear

[kilrau]

Who's interested in this one? @erkarl @sangaman @reliveyy

[kilrau]

@erkarl @ImmanuelSegol is the disconnect cli command working?