Consider making it easier to detect if an event is returned, or if there's no event, or if it's malformed.

[vaikas]

As part of:
knative/eventing#3450
(and the discussions around how to handle empty events...)

Wanted to float by changing the behaviour of:
https://github.com/cloudevents/sdk-go/blob/master/v2/binding/to_event.go#L23

For handling empty responses differently from a malformed event, wanted to see if we could possibly change the semantics of the return to make it easier for the users to reason about the returned events.

As a user I was expecting the following semantics, and wanted to see if we could change to be so:
nil, nil => There was no event and no error.

Currently the user has to check the encoding, read the body/close it and see if any bytes were there themselves. By having the ToEvent code return a nil event and nil error to indicate there was no event there seems nice.

[slinkydeveloper]

Currently the user has to check the encoding, read the body/close it and see if any bytes were there themselves. By having the ToEvent code return a nil event and nil error to indicate there was no event there seems nice.

This behaviour is not defined in the spec, so i don't think it should be part of the sdk. For the spec, a request/response is a cloudevent if has ce- headers or a content-type matching an event format, otherwise it's a non-event. I think it's reasonable for the sdk to mark a message non-event (marking it with binding.EncodingUnknown) as soon as both conditions are false.
If you want to do a particular distinction of no cloudevent 200 with body and no cloudevent 200 without body, then you should handle it specifically in knative. To sdk-go, what makes sense is the only distinction made by the spec: event/non-event.

nil, nil => There was no event and no error.

This is something doable but I think we need to wait v3 for that, since it could break a looot of things