Refactor channel reconnect behaviour

[dirkmc]

Background

Currently we keep track of connections for each channel in two different ways that overlap:

1. The push channel monitor

• Watches the data rate on a push channel, and attempts to restart the channel if the rate falls too low
• Sets timers when waiting for the responder to
  • acknowledge a channel open request
  • send a Complete message when all data has been received

2. Connection monitoring in the event handling code:

• when there's a timeout or disconnect, we mark the channel as being disconnected and set a timer
• when data is sent or received, we cancel the timer
• if the timer expires (by default after one hour), we fire an error event

Note that the connection monitoring in the event handling code is a holdover from a previous version of go-data-transfer which just fired an error event when the connection went down, but didn't automatically try to reconnect

Proposal

• Remove connection monitoring from the event handling code
• Watch for timeouts / disconnects / errors in push channel monitor and attempt to restart the transfer when these errors occur
• Create a pull channel monitor that shares code with the push channel monitor and performs a similar service for pull channels
• The push and pull channel monitors should attempt to reconnect only on the side of the connection that initiated the channel (eg for a filecoin retrieval, only the client should attempt to reconnect).
  On the responding side (eg the filecoin provider) the monitors should fire a Disconnect event instead of trying to reconnect. The layer above go-data-transfer should simply wait until the initiating side tries to reconnect.