Allow overriding of Kafka configurations per producer/consumer

[jhill072]

Problem
From my understanding, configurations for producers and consumers are determined by a single config map, plus or minus a couple of specific properties such as group.id. I would like to be able to control some more properties on a case-by-case basis, and I'll focus on a specific example: auto.offset.reset. Some of my applications may be fine with receiving the same event multiple times, while others may not be able to (or may not want to) understand past events, but I have to choose exactly one per dispatcher. Since the general operation for updating a Trigger is to recreate the Trigger, this results in a new consumer group (and therefore a new offset).

Another similar option on the producer side would be the acks, where we may want higher throughput at the risk of losing some data.

Persona:
Which persona is this feature for? Event producers and event consumers.

Exit Criteria
I can set a property on a Trigger, SinkBinding, etc. that can change the default behavior of a single producer or consumer.

Time Estimate (optional):
How many developer-days do you think this may take to resolve? Based on my quick look into the code, there are events for new egresses and a map for consumer configs that gets instantiated on each new consumer. I would hope to be able to reference labels, annotations, etc. on the Trigger that can override the properties for that particular consumer. That doesn't seem too difficult to iterate over an incoming egress, but naming conventions and ensuring this doesn't break existing users could mean more discussion points/analysis.

Additional context (optional)

[pierDipi]

Hi @jhill072 !

This is definitely useful.

What I was thinking is rather than give event producers and event consumers the ability to set every possible producer and consumer configuration directly, what if we have a set of named profiles (with the ability to define your own) where you can group configurations together and every trigger, broker, etc can choose the profile that best fits that use case?

For example:

t1-profile:
  auto.offset.reset=latest
  # ...
t2-profile:
  auto.offset.reset=earliest
  # ...

The output would be the global set of configurations merged with the profile-specific configurations that the resource chooses.

[jhill072]

That would be fantastic, as I was planning on using this in basically the same way!

[pierDipi]

/triage accepted

This issue depends on #1537 since we're changing the way consumers work and the new model facilitates the implementation of this feature.

[wSedlacek]

I would be interested in this feature being revisited.
Ultimately I am most interested in replaying events to certain triggers.
It would be fantastic if I could set a specific initial offset like was done in the ResetOffset (which was seemingly removed)