Replace chain store's headEvents "pubsub" with a synchronous event bus

[anorth]

Description

The chain store carries a headEvents reference which is a channel-based "pubsub" object from https://github.com/cskr/pubsub. The object supports notification of when a new head tipset is discovered.

The asynchrony forced by using channels complicates, things, and in particular has led to a mutable HeaviestTipSetHandled callback func on the Node purely so that node.TestUpdateMessagePool can tell when the subscriber to that pubsub has finished.

Forcing the use of channels here unnecessary. This use would be much better served by a simple, synchronous event bus like this one. The message pool test could then simply update the head and know that the node has responded when the event post returns.

Note that this pattern doesn't prevent asynchrony for any particular event/subscriber, but makes it opt-in. Reducing unnecessary concurrency, and scoping it tightly, could also help us avoid work and/or headaches of handing concurrency in objects that are transitively reachable from any goroutine (we almost certainly don't handle this properly at present).

Since an event bus is a relatively simple pattern, I suggest we write our own, a simpler version of that linked above. We can then limit & customise functionality to exactly our needs. I expect an event bus will be useful for more than this single use case.

Acceptance criteria

• New heaviest tipsets are notified via a synchronous event bus
• Node.HeaviestTipSetHandled is removed
• github.com/cskr/pubsub is removed from dependencies

Risks + pitfalls

• This will involve a little refactor of the current tipset handling code.
• The referenced event bus does not plumb a Context, but we should

Where to begin

In node.go, understand usage of HeaviestTipSetCh and HeaviestTipSetHandled.

[anorth]

Libp2p have produced a local event bus, see libp2p/go-libp2p#653. On my first reading, it seems to involve mandatory channels (and hence asynchrony), but worth investigating.

[anorth]

The ugly HeaviestTipSetHandled callback has since been purged, but the forced concurrency here is still undesirable.