Fix/clarify handling of empty telemetry/event message payload

From https://github.com/eclipse/hono/pull/3215#discussion_r857397317: A device trying to send a telemetry/event message with an empty payload will get a code 400 error if the content type of the message wasn’t set to application/vnd.eclipse-hono-empty-notification. That behaviour/requirement is not documented.

It’s not obvious why messages with an empty payload require that content type. Before the introduction of that content-type, empty payloads were even not supported at all (see https://github.com/eclipse/hono/pull/596/files#diff-8a5c90291d6bfbbcbd7ae69c43de9a5a5e77532137e677c23fd3e655545d67c5L489).

At least the documentation should be adapted here.

[calohmn]

I am still not convinced of using application/octet-stream as a fallback content type for other empty messages, though. We currently do not support sending empty messages with another content-type than application/vnd.eclipse-hono-empty-notification at all. So I can also imagine to relax this a little and allow devices to send empty messages with any non-null content type instead. WDYT?

Ok, so then the only change for this issue here and Hono 2.1.0 would be allowing messages with empty payload and any non-null content-type. For Hono 3.0 we could do the change towards allowing an empty content-type along with an empty payload.

Concerning the case that an empty device message with no content-type is received and there is a default configured for the device: If the default is application/json for example, setting that content-type for an empty message would result in an inconsistent/invalid message, as an empty payload would not represent valid JSON. Therefore I think it would be better to apply the device-default content type only for non-empty messages.

[sophokles73]

It might even be a bit confusing for downstream application developers seeing messages from MQTT/AMQP devices without content type and payload being mapped to the empty-notification content type, when such empty-notification content type messages are otherwise associated with ttd-messages.

I see your point. AMQP and/or MQTT devices actually have no reason to send empty notifications in the first place.

I can also see the benefit of using the existence of a hono-ttd request parameter in conjunction with an empty and empty content type in the HTTP and CoAP adapters. For CoAP and HTTP devices this would allow them to omit the explicit content-type, thus further reducing request message size.

I am still not convinced of using application/octet-stream as a fallback content type for other empty messages, though. We currently do not support sending empty messages with another content-type than application/vnd.eclipse-hono-empty-notification at all. So I can also imagine to relax this a little and allow devices to send empty messages with any non-null content type instead. WDYT?