Multi-response

[pipermerriam]

What was wrong?

Prior to the PeerBackend system that was recently introduced to trinity there was a single request/response pair that served getting new candidates for peer connections. This proved problematic because we actually wanted/needed multiple sources of new peers.

The backend system works around this by no longer having a generic event for requesting new peers, but rather having each backend source new peers via it's own mechanism.

At the time, lahja operated under a "send everything to everyone" model.

I think there is a valid case to support requests that have many responses.

How can it be fixed?

If we implement #91 then this should be possible. This would either be a new request type, or a flag on the BroadcastConfig which would result in request returning an iterable of responses. Internally, we would tack how many endpoints the request was broadcast to, require them each to ack for which we allow a response event to serve as an ack. The simple ack responses would be discarded, and the actual responses returned.

This also probably suggests that the ack API may need to allow for any response event with a mtaching filter_event_id to serve as an ack rather than restricting it to a single event type.