On demand peer based metrics

[hannahhoward]

What

We want to get an on-demand close look into what is going on for a given graphsync peer. We'll probably use this initially to build an admin endpoint in Estuary to see what we can learn about a given peer.

Sample API (feel free to modify though this should be a good shape to start from):

in root graphsync.go

type RequestState uint64

const (
	Queued RequestState = iota
	Running
	Paused
)

type PeerRequest interface {
	RequestData
	State() RequestState
}

// PeerStats describes the state of graphsync for a given
type PeerStats struct {
	// OutgoingRequests
	OutgoingRequests []PeerRequest
	// IncomingRequests
	IncomingRequests []PeerRequest
}

// GraphExchange is a protocol that can exchange IPLD graphs based on a selector
type GraphExchange interface {
        // ...
        // existing methods
        // ...
        
	// PeerStats produces insight on the current state of a given peer
	PeerStats(p peer.ID) PeerStats
}

Implementation

What we probably want is a new method on RequestManager and ResponseManager, which will need a new message into the system, that will result in a new server method on each that assembles the data from the inProgressStatus map. Unfortunately, this map is not sorted by peer id for the moment so we'll probably need to loop through the whole thing (sad face). We won't be calling this very much though so I'm not so worried.

For discussion

I am getting anxious about the amount of methods on the "GraphsyncExchange" interface. I am thinking we may want to start exposing some of these only on the impl/Graphsync struct, which is public, but folks will have to feature detect for that. I'm particularly concerned about methods like these, that we may or may not want to live by forever. I don't want to keep publishing them in places that indicate they should be used a lot. It seems like only putting them on impl/Graphsync and then having priviliged consumers (i.e. Estuary) to the check might make sense for now.