fix: zenoh_session_multicast test

[YuanYuYuan]

Closes #1002.

[YuanYuYuan]

In the above repeated tests, an unexpectedly slow run is caught. https://github.com/eclipse-zenoh/zenoh/actions/runs/8921424650/job/24501502386?pr=1004#step:7:113

[YuanYuYuan]

As the timeout of nextest is disabled, we found that the ztimeout! within the test appears to be ineffective. We might fail into the issue of tokio::timeout(fut).await never yields whenever the future fut is a blocking call per se.

[YuanYuYuan]

Two issues have been identified:

1. Passed with panicking error.

2024-05-06T04:23:29.255530Z TRACE                    rx-0 ThreadId(10) zenoh_link_udp::multicast: Read error on UDP link 192.168.68.114:55606 => 224.0.0.1:17448: A Tokio 1.x context was found, but it is being shutdown. at io/zenoh-links/zenoh-link-udp/src/multicast.rs:97.
2024-05-06T04:23:29.255557Z DEBUG                    rx-0 ThreadId(10) zenoh_transport::multicast::link: Read error on UDP link 192.168.68.114:55606 => 224.0.0.1:17448: A Tokio 1.x context was found, but it is being shutdown. at io/zenoh-links/zenoh-link-udp/src/multicast.rs:97.

And then the error of "thread rx-0 panicked at ... The hashmap should contain net after initialization..." may occur. It's due to spawning another termination task after the global ZRuntime has been clear.

https://github.com/ZettaScaleLabs/zenoh/blob/936bde67d95d102d6d582e884a1f931956141bd3/io/zenoh-transport/src/multicast/link.rs?plain=1#L384

Log file

2. Failed with timeout error.

zenoh::session::close -> zenoh::net::routing::dispatcher::tables::close_face deadlock found.

https://github.com/ZettaScaleLabs/zenoh/blob/936bde67d95d102d6d582e884a1f931956141bd3/zenoh/src/net/routing/dispatcher/tables.rs?plain=1#L177

(zlock! is the blocking one.)

Log file

To reproduce:

export RUST_LOG="zenoh=trace"
cargo nextest run -p zenoh --test session -E "test(=zenoh_session_multicast)" -F unstable --no-capture

[YuanYuYuan]

Regarding the first issue, the removal of atexit callback is proposed after the discussion. The reasons are listed below,

1. Previously with async-std, we don't have such kind of cleanup on the global runtime.
2. Since Rust doesn't drop the static variable, we need to add this cleanup callback to pass the memory leak check with Valgrind.
   However, we can workaround it by the previous solution "a runtime guard" as well.
   The downside of the previous solution is users may find the memory leak reported by Valgrind in our examples or the bindings that no runtime guard is used by default.
3. We found that the unsafe atexit is unsound. For example, we got the following error if we tried to log with tracing while dropping ZRuntimePool.

thread '<unnamed>' panicked at 'use of std::thread::current() is not possible after the thread's local data has been destroyed', library/std/src/thread/mod.rs:711:35
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Moreover, we still have an unresolved issue with Windows DLL. See #973 for details.

Once we remove the atexit cleanup, the first issue should disappear including the panics found on rmw_zenoh.

[YuanYuYuan]

The first issue has been addressed via #1015