feat(v2): full implementation for kafka bindings

[PlugaruT]

Changes

• Full implementation of Kafka bindings

One line description for the changelog

• Tests pass
• Appropriate changes to README are included in PR

[PlugaruT]

@xSAVIKx here's another one.

Another topic that I'd like to discuss is what would be the approach next? I'd like to remove entirely v1 package from v2 branch and start working towards a possible release? Since I think both v1 and v2 would be with the same feature set.

Also, what's your take on the protocol implementation? I took a look at go sdk for example, and they implemented the full Kafka protocol and integrated it with confluent-kafka-go lib for example, I assume same can be said about MQTT and other protocols. Do we plan to add support for this? Or, we want to keep the package light and allow users to define the protocol how they see fit?

[PlugaruT]

@xSAVIKx ping, in case you somehow missed the notification. thanks

[xSAVIKx]

Hey @PlugaruT , thx for the ping. I did miss it.

I will try to get back with an answer and a review later today. Thank you 🙏

[xSAVIKx]

@PlugaruT LGTM 👍

Let me know if you want to handle those suggestions. But it can be done separately as well.

[xSAVIKx]

this is a perfectly correct implementation, I was just thinking that 99% of users will do what you added in the example:

from_binary(message, JSONFormat(), CloudEvent)

It probably is a good idea to have this shortcut for them as well. Maybe with smth like:

cloud_event_binary_from(message)

WDYT?

[xSAVIKx]

and similarly here we can provide a shortcut like:

cloud_event_structured_from(message)

[xSAVIKx]

Another topic that I'd like to discuss is what would be the approach next? I'd like to remove entirely v1 package from v2 branch and start working towards a possible release? Since I think both v1 and v2 would be with the same feature set.

IMO it is a good idea to release a first v2 version with v1 compatibility package. And then remove the compatibility package in a follow-up release.

Also, what's your take on the protocol implementation? I took a look at go sdk for example, and they implemented the full Kafka protocol and integrated it with confluent-kafka-go lib for example, I assume same can be said about MQTT and other protocols. Do we plan to add support for this? Or, we want to keep the package light and allow users to define the protocol how they see fit?

the main package should be kept lightweight - that's for sure. we can implement the full support for a desired library/libraries as optional deps or separate packages IMO.