fix: use specific tokio features instead of "full"

[zond]

Summary

• Replace tokio = { features = ["full"] } with specific features
• Add optional tokio-full feature for rt-multi-thread and signal
• Enables building reticulum-rs for embedded platforms like ESP32

Problem

The "full" feature includes signal handling (signal-hook-registry) which uses POSIX signals not available on all platforms. Specifically, ESP-IDF's libc lacks:

• siginfo_t, SIGKILL, SIGSTOP
• SA_RESTART, SA_SIGINFO
• Full sigaction struct

This prevents reticulum-rs from compiling for ESP32 targets.

Solution

1. Use minimal tokio features by default: rt, net, io-util, sync, time, macros
2. Add tokio-full feature that enables rt-multi-thread and signal
3. Include tokio-full in default features for backward compatibility
4. Mark examples as requiring tokio-full since they use #[tokio::main] and tokio::signal

Usage

# Desktop (default) - includes rt-multi-thread and signal
cargo build

# ESP32/Embedded - minimal tokio features
cargo build --no-default-features --features alloc

Testing

• ✅ Library builds with defaults (x86_64)
• ✅ Examples build with defaults (x86_64)
• ✅ Library builds without tokio-full (ESP32 mode)
• ✅ Successfully built for ESP32-S3 (xtensa-esp32s3-espidf target)

🤖 Generated with Claude Code

[doubleailes]

I think you need also: "rt-multi-thread","signals"` to build the examples over arch x86_64

[zond]

I think you need also: "rt-multi-thread","signals"` to build the examples over arch x86_64

Thank you - now I also made tokyo-full a feature, and made examples depend on it. See if this is better?

[contra-bit]

I think it would make sense to create a workspace, where the base Reticulum crate has the minimum amount of dependencies and create separate crates for the CLI or embedded applications which now live in examples.

In #57 I have added toml and dirs as dependencies since they are required for config parsing, but the actual network library does not require this. So it would be better to have them in a separate crate.

[zond]

I think it would make sense to create a workspace, where the base Reticulum crate has the minimum amount of dependencies and create separate crates for the CLI or embedded applications which now live in examples.

In #57 I have added toml and dirs as dependencies since they are required for config parsing, but the actual network library does not require this. So it would be better to have them in a separate crate.

I agree that separating the code into crates for pure routing and crates for things with more dependencies would be productive, but I'm currently just interested in the minimum change to make it work for me. Maybe later when I'm more familiar with the Reticulum-rs codebase I would dare suggest bigger refactors. In general I feel bigger refactors are the domain of regular maintainers.

[kujeger]

I think it would make sense to create a workspace, where the base Reticulum crate has the minimum amount of dependencies and create separate crates for the CLI or embedded applications which now live in examples.

In #57 I have added toml and dirs as dependencies since they are required for config parsing, but the actual network library does not require this. So it would be better to have them in a separate crate.

the #21 pr creates a workspace, but until the maintainers make a decision on if/how/when they want to refactor into a workspace with multiple crates, it's going to be a bit of an effort to keep such a restructuring current with main -- and having other patches depend on a bigger changeset like that is going to be just pain all around