triggers: Proposal to move TriggerBinding-TriggerTemplate connection out of TriggerBinding definition

In the docs for TriggerBindings, we say:

Although similar, the separation of these two resources was deliberate to encourage TriggerTemplate definitions to be reusable

I don’t disagree with this idea and I don’t think TriggerTemplate reusability should change.

However, for many users, it may end up being even more important for TriggerBindings to be reusable! TriggerBinding reusability is severely limited in the current design because within the definition, a specific TriggerTemplate is referenced within the TemplateRef.

To give an idea of what I’m saying, imagine a user who is getting tons of GitHub events from various contexts/sources. Depending on the situation, the user has defined several TriggerTemplates, and each will execute different jobs like building code, performing test, moderating comments, etc. Now, for each of those TriggerTemplates, which are intended to be called upon separately in differently contexts, the user must completely redefine or copy-paste the payload->parameter logic, because that information is within TriggerBinding, which is tied to a specific TriggerTemplate via TemplateRef. This could become extremely tedious especially for users with complex payloads.

Bottom line, I think TriggerTemplates and TemplateRefs should each be reusable for their own reasons, and the way to do this is to move the TriggerBinding→TriggerTemplate connection representation out of the TriggerBinding itself. This could be done by moving the connection information a layer up into EventListener, or to create a new resource, representing that connection and possible conditional logic and then listing those new connection resources within EventListener.

My proposal would be to move the connection information into EventListener. This would mean removing the templateRef field from TriggerBindings, and then an EventListener could look something like this:

apiVersion: tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: simple-listener
spec:
  connections:
    - triggerBinding: simple-pipeline-binding
      triggerTemplate: simple-pipeline-template
    - triggerBinding: another-pipeline-binding
      triggerTemplate: another-pipeline-template

Conditional/filtering information would also go within the connections field. This way, the payload-variable logic is truly encapsulated and reusable within triggerBinding. I see EventListener analogous to a PipelineRun or TaskRun, in that it provides project-specific configuration details like connections, filtering, or perhaps default parameter/payload values, while triggerBinding and triggerTemplate can be reused as needed.