Expected host behavior when message properties are not supported for implementation

Support for content-type and metadata/headers across different message queues and services is not uniform. For example, RabbitMQ has built-in support for content-type, but NATS.io does not.

What's the correct behavior on the host's part when content-type and/or metadata is set in the guest message, but not supported by the underlying implementation?

In scenario where a message is received by the guest via incoming-handler#handle, the resource is associated with the concrete implementation of a message queue it originated from, therefore we can make assumptions on which properties are supported and which are not (like is done in https://github.com/WebAssembly/wasi-messaging/pull/29)

In cases, where the guest constructs a message, it will only be associated with a concrete message queue once it's passed as a parameter to e.g. producer#send. What is the expected behavior for the host in case e.g. a guest message with content-type set is passed to a types.client, which is associated with NATS.io, which does not support content-type?

One potential solution I see here is:

• Exposing supports-metadata: func() -> bool and supports-content-type: func() -> bool on types.client
• Removing https://github.com/WebAssembly/wasi-messaging/blob/4ee59bb881f7a8675fbb3ae7ca5d5d586ab88657/wit/request-reply.wit#L46
• Exposing reply as a getter on the message, therefore enforcing that replies are sent using a specific types.client via producer#send
• Adding remove-content-type to message

With this functionality, I think we can enforce that, e.g. passing a message carrying content-type to producer#send using a client, which does not support it, results in a hard error.

Another potential improvement here is removing the message constructor altogether and instead, exposing a new_message method on the client.

It looks like there also should be some way to derive a client from an incoming message

Start by reading wit/types.wit, wit/producer.wit, wit/guest.wit, and wit/request-reply.wit, then review the linked incoming-handler#handle and producer#send definitions. The issue needs a settled decision on unsupported message properties, client and message relationships, constructors, and reply handling; done means the chosen behavior and required WIT API changes are specified.