Use `Queue` from cats-effect for events

[olynch]

I suspect that our current solution for getting events, which is by binding one-off listeners every time we listen to an EventStream in the IO monad, is causing some events to drop in the intermediate time between when we've finished processing an event and when we install the next event handler.

Instead of binding one-offs, we should just have an observer on the EventStream which sends events to a Queue, and then interact with the Queue from IO code.

The original design was because I thought that we might want to wait on arbitrary EventStreams in IO. But it seems like we mainly just listen to a single EventStream, so it makes sense to make an IO-native object that shadows that EventStream.

[olynch]

It looks like the correct way to do this is by using a Dispatcher: https://typelevel.org/cats-effect/docs/std/dispatcher

[olynch]

One question is what type of Queue to use.

A Queue may be constructed with different policies for the behaviour of offer when the queue has reached capacity:

• bounded(capacity: Int): offer is fiber blocking when the queue is full
• synchronous: equivalent to bounded(0) - offer and take are both blocking until another fiber invokes the opposite action
• unbounded: offer never blocks
• dropping(capacity: Int): offer never blocks but new elements are discarded if the queue is full
• circularBuffer(capacity: Int): offer never blocks but the oldest elements are discarded in favour of new elements when the queue is full

I think that what might make the most sense is either an unbounded Queue (which could potentially cause a space leak), with perhaps a warning printed if the Queue grows too big so we can fix the space leak. In general, as long as we handle everything which comes out of the Queue we should be fine.

[olynch]

Done.