feat(*): Updates messaging to support request-reply

This makes several updates to the messaging interface. Initially the
README said that this wasn't going to support request/reply, but based
on my reading of the Kafka, NATS, MQTT, and SQS APIs, this is a fairly
common pattern. Another piece of evidence here is what I've seen as a
wasmCloud maintainer from our users. Request/reply is one of the more
common things we see with a messaging service. Please note that this
doesn't _require_ the use of a reply-to topic, just exposes it for use.

I also did a few other changes here. First is that I added the topic to
the message. This was common across all systems and is often used by code
to select the appropriate logic to perform. I also removed the format
field as this didn't seem to be a common parameter across various services.
We could definitely add a content-type member to this record in the future
if needed, but I think much of that can be passed via the metadata field.

There are other things I might suggest some changes to, but I want to think
on them some more and open some issues to discuss them first

Signed-off-by: Taylor Thomas <[email protected]>

Author: thomastaylor312

README.md

@@ -45,7 +45,7 @@ Overall, the messaging interfaces aim to make it easier to build complex and sca
 ### Non-goals
 
 - The messaging service interfaces do not aim to provide advanced features of message brokers, such as broker clustering, message persistence, or guaranteed message delivery. These are implementation-specific details that are not addressed by the interfaces.
-- The messaging service interfaces do not aim to provide support for every possible messaging pattern or use case. Instead, they focus on the common use cases of pub-sub and push-based message delivery. Other messaging patterns, such as request-reply or publish-confirm-subscribe, are outside the scope of the interfaces.
+- The messaging service interfaces do not aim to provide support for every possible messaging pattern or use case. Instead, they focus on the common use cases of pub-sub, push-based message delivery, and request-reply. Other messaging patterns, such as publish-confirm-subscribe, are outside the scope of the interfaces.
 - The messaging service interfaces do not aim to provide a specific implementation of a message broker. Instead, they provide a standard way to interact with any message broker that supports the interfaces.
 
 ### API walk-through

wit/producer.wit

@@ -1,5 +1,7 @@
 interface producer {
     use messaging-types.{client, channel, message, error};
 
+    /// Sends a message to the given channel/topic. This topic can be overridden if a message has a
+    /// non-empty topic field
     send: func(c: client, ch: channel, m: list<message>) -> result<_, error>;
 }

wit/types.wit

@@ -23,22 +23,15 @@ interface messaging-types {
         extensions: option<list<tuple<string, string>>>
     }
 
-    /// Format specification for messages 
-    ///  - more info: https://github.com/clemensv/spec/blob/registry-extensions/registry/spec.md#message-formats
-    ///  - message metadata can further decorate w/ things like format version, and so on.
-    enum format-spec {
-        cloudevents,
-        http,
-        amqp,
-        mqtt,
-        kafka,
-        raw
-    }
-  
-    /// A message with a binary payload, a format specification, and decorative metadata.
+    /// A message with a binary payload and additional information
     record message {
+        /// The topic or subject this message was received or should be sent on
+        topic: string,
+        /// An optional topic for use in request/response scenarios
+        reply-to: option<string>,
+        /// An opaque blob of data
         data: list<u8>,
-        format: format-spec,
+        /// Optional metadata (also called headers or attributes in some systems) attached to the message
         metadata: option<list<tuple<string, string>>>
     }
 }