Proposal: First-class support for message keys about proximo HOT 3 CLOSED

Since I no longer work at UW I don't really have the time to take a look into this anymore. If someone wants to adopt my draft implementation or just rewrite their own please do :)

from proximo.

I've added a draft implementation in #93

from proximo.

To add to this issue, we also have a situation that needs the use of the message key.
This is in the context of the legacy.account.events that we consume from the bespoke promixo server in front of the account / identity kafka q.
We want to project the messages that we receive to a Kafka queue of our own for use by our domain consumers.
Our requirement is to use log compaction on our topic (much like a&i do). For this to work "out of the box" we need to be able to retain the message key.

As pointed out in this issue's description, message keys are pivotal to several messaging systems. Without the flexibility to support message keys, it could be argued that as it stands, proximo is opinionated about what a message is. Paradoxically, this makes proximo more message-centric and less abstractive of the backend messaging system.

from proximo.