Split up Dispatcher

[kristinapathak]

Dispatcher really be two different components/structs/interfaces:

• one thing that has a queue and decides whether or not to send an event given the device id / norn (give this a different interface name)
• one thing that is configured to the specific endpoint, which can be used by multiple of the first thing (this should be called the dispatcher since it is actually dispatching the event)

They shouldn't be the same interface, because given the interface here:
https://github.com/xmidt-org/mimisbrunnr/blob/main/dispatch/dispatch.go#L54

• The filtering struct needs to know the deviceID, but the dispatcher doesn't care.
• When we add cut off functionality, the interfaces will likely diverge more.

They will likely both need to be updated, but exactly how that works I haven't thought through. Given that multiple filtering interfaces will use the same dispatcher, the manager should have some map/list/something for each dispatcher in order to pass along an existing dispatcher to a newly created filtering struct thing.

Some things I thought of but haven't fully thought through yet:

• Though they both need to be updated, it might be that the manager will split up a norn's information and update them separately? Also - what happens if just one endpoint is updated with new auth information? (this could be a good reason to have separate dispatchers for each filtering struct but would make it difficult to cut off all dispatchers to a specific endpoint)
• How do we know a dispatcher is no longer being used by any filtering structs in order to clean it up from the manager?

[kristinapathak]

No need for the manager to split up the norn's information - just update both the filterer and the dispatcher with the norn and they can figure it out.

The manager will be responsible for keeping its map of endpoints to dispatchers up to date and pruning out unused ones based on the new list of norns from chrysom.