`ws-kafka` feature

[jfallows]

One significant issue with mapping websocket to kafka is the choice of protocol format after establishing the websocket transport to potentially handle:

• binary key
• binary header values, with text header names
• text payload
• binary payload
• progress indicator, stateless resumption
• transport connection reuse
  • multiplexing protocol over http/1.1 websocket
  • single stream protocol via http/2 websockets, http/2 transport handles multiplexing

Consider instead implementing support for the following:

• rsocket over ws or http/2 streams
• socket.io over ws
• stomp over ws
• mqtt over ws

As a starting point, we can add a ws-kafka binding, that behaves as follows:

• send and receive message payloads only, as text or binary frames
• inject message key or headers during client send, similar to http-kafka binding
• filter by message key or headers during client receive, similar to http-kafka binding
• support replay of historical messages, or only new messages after connecting
• no reconnect behavior or guaranteed message delivery

[slachiewicz]

It would be good to have the possibility to use different protocols inside websockets like for emobility OCPP