feat(WIP): adding uniffi bindings to support android and ios

[sebasti810]

Mobile bindings for Lumina node via UniFFI

This PR adds iOS and Android bindings for the node using Mozilla's UniFFI.
I followed the approach from wasm and tested it successfully in the iOS and Android simulator.

Current State

• Basic node operations (start, stop, querying, etc.)
• Platform-specific storage paths
• Event handling
• Example projects for iOS and Android

TODOs

• Improve runtime (using #[uniffi::export(async_runtime = "tokio")])
• Improve error handling
• Improve types
• Add docs
• Finish and test example projects

[oblique]

We refactored how we construct a Node. We introduced NodeBuilder and made private the NodeConfig. So this PR needs an update.

[sebasti810]

@oblique i rebased, now it works again. test-wasm ci will still fail at the moment. Should I make the crate wasm compatible or should we just ignore it and use something like:
cargo clippy --workspace --exclude native --all-targets --target=wasm32-unknown-unknown -- -D warnings
instead of:
cargo clippy --all --all-targets --target=wasm32-unknown-unknown -- -D warnings

[zvolin]

thank you for the contribution, we're supper happy about it and would love to getting it upstream 🙇

[zvolin]

test-wasm ci will still fail at the moment. Should I make the crate wasm compatible or should we just ignore it and use something like

I think we don't care about wasm in this new crate so you could just put this in top of lib.rs

#![cfg(not(target_arch = "wasm32"))]

[sebasti810]

I think we don't care about wasm in this new crate so you could just put this in top of lib.rs

#![cfg(not(target_arch = "wasm32"))]

true, that's enough. I thought we would then have to update the Cargo.toml etc. as well with target-specific dependencies, but that is not the case. Thank you

[oblique]

Can we use the one from lumina-node crate?

[sebasti810]

We can, but I haven't yet found a solution to make PeerId from libp2p and Vec<u16,u16> compatible with uniffi without the specific wrappers i wrote in types.rs. Afaik, e.g. tuple types are not directly supported because they cannot be cleanly mapped to equivalent types in different target languages. Of course, I could bring the wrappers into the lumina node if that's wanted :)