Broker requires unnecessary event deliveries

[grantr]

Problem
Imagine a Source github delivering 100 events per second connected to a Broker with 10 triggers, none of which are interested in events from github. The Broker will persist each of those 100 events in its channel, and deliver each one 10 times, for total delivery of 1000 events per second to the filter, all of which are immediately dropped.

A source delivering an event to a Broker doesn't know if the event is interesting to any consumers. The source must deliver all events that could be interesting, even if none of them are interesting. The Broker will then persist all of those events in its internal channel, deliver them once for each Trigger, only for the filter to drop each one individually.

The current workaround for this issue is to ask users to configure sources with specific filters that are duplicates of the trigger filter, but that's prone to error and eliminates the stated benefit of the Broker being able to abstract away message routing.

The Broker and source should coordinate so the uninteresting event is dropped as far upstream as possible.

Persona:
Operator

Exit Criteria
An event that is not subscribed to by any Triggers is dropped upstream of the Broker's ingress.

Time Estimate (optional):

Additional context (optional)
Related to #934

[lionelvillard]

Related to broker capabilities, in particular whether the broker supports event replay. In that case the broker should still receive and store events but should not forward them until the creation of a Trigger interesting in github events.

[matzew]

I like the idea of the reply here

[grantr]

/area performance

[davyodom]

The single channel design of the broker is also causing many unnecessary deliveries on the subscriber side. It would be better to group related events into different channels, and triggers would only have subscriptions to the correct channels (and therefore subsets of events) and not to 100% of events sent to the current single broker channel. This would also seem to be necessary for features such as replay, performance or security isolation of different event types, etc. Does this belong here or would it make sense as another issue?

[grantr]

/milestone clear

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.