Track actual network operations in a response

[hannahhoward]

Goals

Provide a way on the responding side to know how much data has gone over the wire and to know when actual network errors occur

Implementation

Essentially, or goal here is a pub-sub system to escalate asyncronous notifications back through the chain of callers to provide information to the response manager about what actually happened with data it attempted to send over the wire

• build a simple pub/sub topic system, with with a key feature -- the ability to remap topics -- I subscribe on one topic but receive notifications on another
• in the message queue, publish notifications when things happen with a message: it's queued, it's successfully sent, or an error occurs
• the the peer response sender use the queue event to insure one messages is processed at a time, and republish response sender events based of the message event
• in the response manager map semantically meaningful topics on to response sender events -- so that when we receive a sent or an error, we have all the information we need to react to it
• convert listeners to only taking the requestID -- it strikes me that someone listening should already have picked up the request ID from an incoming request hook. Also, this makes it much easier to pack relevant information into the topic
• listen for semantically meaningful events and now pass on to two new hooks -- OnBlockSentListener -- listens for when the block actually goes over the wire, and NetworkErrorListener -- listens for when a message going over the wire encounters an error
• refactor the peerresponsesender and response manager tests significantly -- these were both extremely verbose

For Discussion

It's possible the notification system is unneccesarily complicated. It seems like a useful tool for the future though.

[rvagg]

Wow, that's quite a bit of code! I wish I could help with a meaningful review, I've done a skim but I don't think I have anything helpful to add. So 🤷 if it seems to be working then you're in the best position to make a call on it. This doesn't do anything at the protocol level, does it? Alternative implementations don't need to care about anything you've added here do they?

[hannahhoward]

@rvagg I appreciate the review... it's unfortunate that I don't have a better guide to this code... once I've got distance form filecoin I'm going to work on making this code base simpler.

In the meantime,

Nope, no protocol changes. Alternative implementations would only care in as much as they want to provide the same functionality to their consumers... (i.e. effective notifications about what's going on with your request) -- which is to say, completely optional.