[Low prio] Add Watch() method to watch pubsub updates

[hsanjuan]

Playing here a bit.. I would like to have a tool that I can use to watch IPNS-pubsub updates without having to run ipfs, just by running a libp2p node connected to the swarm. It seemed that this would help.

This method returns a channel on which all pubsub updates for a key are sent.

Channels are closed when Cancel() is called on a key.

Updates are sent to all channels which have registered for a key (one per call
to Watch()).

[lanzafame]

I could be wrong but there is no difference between deferring the RUnlock here as opposed to right under the call to RLock? And it would be clearer if the defer was right after the lock. For example:

	watchChannels.mux.RLock()
	defer watchChannels.mux.RUnlock()

	p.watchMux.RUnlock()

[lanzafame]

godoc?

[Stebalien]

This looks related to:

https://github.com/libp2p/go-libp2p-routing/blob/29f1089de6a0826ecf62d20cddd8bb0930d54fb2/routing.go#L54-L62

That's my attempt at a value-store independent version of this. I started implementing it for the DHT but decided to punt as we had more pressing issues.

1. What do you think of the interface?
2. Would that interface make sense here?

[Stebalien]

I'd consider:

1. Adding a buffer size of 1.
2. Replacing the buffered value in this case.

That is,

select {
case ch <- data:
case <-ch:
    ch <- data
}

That way, the user always gets the latest value.

[hsanjuan]

What do you think of the interface? Would that interface make sense here?

Well yeah, this is basically an implementation of that interface. However it looks weird that with that interface it's not possible to control subscriptions so a GetValue() leaves a thread running there that can't be removed. And same would be with SearchValue() (unless we cancel the subscription on context cancellation, but that might screw with later calls to GetValue() calls).

Also seems options are unused, but we'd have to think what happens when GetValue is called with some options and SearchValue with different ones (do we keep separate subscriptions for each or just filter?).

All that said, the interface makes sense for what it is (a KeyValueStore user should not have to worry how things are working below, whether subscribing or something else). And we can always adopt the interface signature for SearchValue and improve later.