Nolocal close

[yellowhatter]

Implement close in the way it can be safely waited and awaited in atexit

[evshary]

It still failed when I tested with the following code

use std::sync::OnceLock;
use zenoh::{Config, Session, Wait};
static SESSION: OnceLock<Session> = OnceLock::new();

fn main() {
    let s = SESSION.get_or_init(|| zenoh::open(Config::default()).wait().unwrap());
    println!("> zid: {}", s.zid());
    unsafe { libc::atexit(close_session) };
}

extern "C" fn close_session() {
    SESSION.get().unwrap().close().wait().unwrap();
}

[yellowhatter]

It still failed when I tested with the following code

use std::sync::OnceLock;
use zenoh::{Config, Session, Wait};
static SESSION: OnceLock<Session> = OnceLock::new();

fn main() {
    let s = SESSION.get_or_init(|| zenoh::open(Config::default()).wait().unwrap());
    println!("> zid: {}", s.zid());
    unsafe { libc::atexit(close_session) };
}

extern "C" fn close_session() {
    SESSION.get().unwrap().close().wait().unwrap();
}

Tokio (and some other nolocal-unsafe libs) does not allow interacting with it's objects from atexit handling thread. However, already existing threads (including those dedicated to the async runtime executor) are ok to do that, even during concurrent atexit execution.

The current Close implementation in this PR does not intend Session::close to be called inside atexit, it just allows waiting inside atexit for prior started nonblocking close to complete - that's why you get panic. This was enough to fix rmw errors in scenario I tested - but now I see we need more comprehensive thing.

It is possible to make close to be both callable and waitable inside atexit. The logic will be: upon Session creation a close task is spawned. This task asynchronously awaits for nolocal-safe async primitive (based on async_channel) to be triggered. This task will stay inactive for the whole Session lifetime. Once the primitive is triggered (from elsewhere, even from atexit), the task will proceed and execute asynchronous internal close routine.
In other words, this is a reverse approach on how NolocalJoinHandle is implemented in this PR.

@Mallets @evshary I will implement the described approach in this PR next