Provide builtin filter function(s)

[lionelvillard]

Problem
Several Knative eventing components rely on filtering (Trigger and the proposed Choice object). It should be a builtin function, or a set of builtin functions.

I'm more in favor for multiple builtin functions, one per data model (eg. Json, XML, Proto, etc..). For instance I wouldn't use CEL for filtering XML data.

Persona:
Which persona is this feature for?
Event consumer

Time Estimate (optional):
How many developer-days do you think this may take to resolve?
1 day

Additional context (optional)
Add any other context about the feature request here.

https://docs.google.com/document/d/17_6ONVtE397X_H5J0mlzvJKiqFWzoHLOqapis6f7nlo/edit

• Advanced Filtering on Triggers Advanced Filtering on Triggers #930
• Add content-based event filtering Add content-based event filtering #1310
• Be able to easily define branches: Be able to easily define branches #1525

[aslom]

Could filters be generalized to have non-boolean return values? Then they could be used to choose branches in #1529 ?

[aslom]

I was assuming that choice has one function that will choose where to send event as that would be more efficient. Right now I think the choice is evaluating a filter for every subscriber - so there is constant work required even if event is not sent anywhere? How would spec.exclusive work - will there be additional (optional) function referenced in yaml? And that means that filters in cases would be optional too? Based on 300-choice.yaml filters are not optional?

The possible options are then between current:

if filterA(event) then
  send event to subscriberA
if filterB(event) then
  send event to subscriberB
…

versus spec.exclusive

switch predicate(event) 
case ‘A’
  send to subscriberA
case ‘B’
  send to subscriberB
…

[lionelvillard]

Choice can be optimized by generating routing tables (see #1396), from filtering or predicate expressions.

[lionelvillard]

Is this issue out of scope? If so, should we close it?

[n3wscott]

Would built in functions or a language be better? See #3359

[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.