fixes *mut esp_netif_obj not Sync compiler error

[cs-clarence]

Fixes #56 (again).
Implements a new type wrapper SendSyncPtr for arbitrary pointer types and impls Send and Sync on that wrapper. This is just an assertion for the compiler and assumes that the underlying apis from the sdk are relatively thread safe.

[ivmarkov]

Fixes #56 (again). Implements a new type wrapper SendSyncPtr for arbitrary pointer types and impls Send and Sync on that wrapper. This is just an assertion for the compiler and assumes that the underlying apis from the sdk are relatively thread safe.

There is no such thing as "relatively" thread safe. Either they are thread safe (i.e. you can call methods on the pointer concurrently, from any thread - so you can unsafely "proclaim" the raw C API as Send + Sync) or not. If it is not, and you still mark it as Send + Sync you'll be ending up with Rust UB = weird crashes/misbehaviors in your program, which is against the whole point of using rust in the first place.

esp_netif_t is not thread-safe, contrary to what the ESP IDF documentation says. Did you read this? It is right there, in #56.

What you are doing with this PR is a bit to blindly apply Send + Sync to a bunch of raw C APIs. This is very dangerous. Each API has to be reviewed in detail as to if it can be proclaimed Send + Sync (i.e. "thread safe").

The event loop might be thread safe. The Netif API, as per above - is just not (data races between reading the Netif state and another thread modifying the Netif state).

I'll address the await + tokio::sync::Mutex topic in the issue, a bit later.