Stateless events on the bus

Nobody has claimed this yet.

As discussed offline with @Stebalien, it might be useful to have events that signal that something/some state could possibly have changed. The consumer can then go fetch the current/latest state from the single source of truth and determine if the relevant state has indeed changed.

One example of this is the `PeerProtocolsUpdated` event. Instead of publishing the diff on the event i.e. Added/Removed protocols, we could publish a `PeerProtocolsChangeEvt` which would be published when we connect to a peer, disconnect from a peer, when it sends us an `ID Delta` etc etc. The consumer can then check the peerstore to see if the remote peer still supports the protocols it is interested in/form a diff based on the previous state and act accordingly.

Start by reviewing the event bus handling for PeerProtocolsUpdated and the peerstore interactions described in the issue. Determine the scope and semantics of a stateless PeerProtocolsChangeEvt, including its triggering events; done requires an agreed design and corresponding behavior for consumers.

Written by the indexing model from the issue text.