Isolate delivery library

[jazzz]

Problem

embedded-logos-delivery is not usable as a crate, as it assumed it was going to be used as a Libchat::DeliveryService which is not always true. LogosDelivery has no plans to support a rust binding, which makes using delivery for other tools.

Solution

Split the embedded logos-delivery transport into two layers:

• logos-delivery (new crate at extensions/logos-delivery-rust/ — owns everything tied to the native node: the raw FFI (sys), the safe synchronous FFI wrapper (wrapper::LogosNodeCtx), and a generic, transport-agnostic ThreadedDeliveryWrapper that runs the node on a dedicated thread. It re-exports P2pConfig, DeliveryError, WakuEvent, and ReceivedMessage.
• embedded-logos-delivery — now a thin adapter over that wrapper. It keeps only the delivery-specific concerns: mapping AddressedEnvelope.delivery_address ↔ the /logos-chat/1/{addr}/proto content topic, filtering to the /logos-chat/1/… prefix, and decoding payloads to raw bytes.
• The links = "logosdelivery" native-link declaration moves to the new crate accordingly.

Key changes

• Generic wrapper. ThreadedDeliveryWrapper takes a caller-supplied FnMut(WakuEvent) -> Option mapper that runs on the callback thread, so filtering and decoding happen inline and the inbound queue yields exactly the type the caller wants. embedded-logos-delivery instantiates it as ThreadedDeliveryWrapper<Vec>.
• Real subscribe/unsubscribe. Node operations are now modeled as a NodeOp enum (Publish / Subscribe / Unsubscribe) serialized through the node thread. DeliveryService::subscribe routes to the node instead of being a no-op, and a matching unsubscribe is added.
• Workspace wiring. Adds extensions/logos-delivery-rust as a workspace member and the logos-delivery path dependency.

[kaichaosun]

[nitpick] define CHAT_TOPIC_PREFIX first and reuse it here.

[jazzz]

sure.

[!] All topic definitions need to be defined in core to maintain interop, so this won't last long but lets keep it clean.

[kaichaosun]

[suggestion] The thin wrapper in this crate can be moved to logo-chat, make it a separate crate looks like a overkill.

[jazzz]

I'm not sure I am following here. As I see the history here.

1. The trait implementations(DeliveryService, Transport) were moved from a high level app to components so they could be re-used. Componentize logos delivery #148
2. In feat: separate embedded logos client #166 you wanted to separate it to its own crate ref: feat: separate embedded logos client #166 (comment)

Now I'm understanding the suggestion is to move the trait implementations to logos-chat which would undo this, by making a transport impl un-accessible again.

I'm worried this is going in circles.

[kaichaosun]

Now I'm understanding the suggestion is to move the trait implementations to logos-chat

My thoughts on these changes are that we have separated logos-delivery, and clear feature gates in definition and its usage. The trait can be moved to the places that meets this target, make it an extra crate looks not the best in current shape, since:

• the logos-delivery-rust is splited
• logos-chat has been splited

This is a general suggestion, I'm happy to take any path you decide on it.

[jazzz]

Very much agree, that embedded-logos-delivery should not be a crate.