Support binary form of Cloud Events about quarkus-reactive-messaging-http

[fjtirado]

@ricardozanini After taking a closer look, in order all connector to behave similarly, it would be good for HTTP Connector, following the metadata approach implemented in other connectors, to generate metadata that implements CloudEventMetadata.

[ricardozanini]

We might consider supporting CE SDK in this extension. @cescoffier thoughts?

[cescoffier]

We tried to use the CE SDK a long time ago in other connectors. We decided to go without it as it brought lots of complexity (dependencies and co).

[fjtirado]

@cescoffier Thanks for quick response. What are you using to support CloudEvent binary in other connectors?

[cescoffier]

We do the work ourselves. It's straightforward.
Here is the example for Kafka:
https://github.com/smallrye/smallrye-reactive-messaging/blob/main/smallrye-reactive-messaging-kafka/src/main/java/io/smallrye/reactive/messaging/kafka/impl/ce/KafkaCloudEventHelper.java.

We have the same for AMQP 1.0.

Note that the Cloud Event metadata is attached to the message metadata.

[fjtirado]

@cescoffier
Ok, makes sense.
I was currently reviewing the code and considering not doing anything in the extension, since for HTTP the headers are already available in the IncomingHttpMetadata
@MarianMacik @ricardozanini I think this issue can be closed. It is kogito responsibility to process the headers in the attached metadata to build the cloud event.

[ricardozanini]

My idea was to add CE in this extension since others might find it useful. It's messaging after all and its highly related to Knative, which transports CE over HTTP.

We can control the CE support via properties, so users might optionally switch on or off.

I'd leverage the same approach @cescoffier pointed for the others extensions rather than the SDK. @cescoffier I agree that the SDK was somewhat complicated in the past, but today it's pretty consolidated, they even have examples using Quarkus. Worth taking a look.

[fjtirado]

@ricardozanini As @cescoffier shown, other connectors are providing cloud event attributes through Message metadata. In order to to do that, SDK is not useful, but a nuissance. It would be different if the Message payload provided by the connector is expected to be a CloudEvent. Changing http connector to send cloudevents in the Message palyload will make it diverge from other connectors and I do not think we want to do that.
On the other hand, it would be nice if other connectors can be configured to return CloudEvent (no matter if binary or structure) in the payload, making the consumer of those events ignorant of the underlying cloud event format ( I mean binary or structure) used (but Im not sure if this is feasible, probably not)

[fjtirado]

Created PR #80