Improve ZRuntime

[YuanYuYuan]

Closes #892.

• Document the configuration.
• Extend the configuration of runtime like controlling the max_blocking_threads.
• Runtime handover.
• Optimize the minimal threads for ZRuntime(currently 5 x 2 = 10). UPDATE: now it's one for each. Only the default of RX is two.
• Add std::fmt::Display for ZRuntime . Replaced by serde and rename.
• Formalize the configuration via an environmental variable with ron. For example, we can configure it like ZENOH_RUNTIME = "(app: (worker_threads: 4), net: (worker_threads: 3, handover: app))".
• Auto static variables clean up

[YuanYuYuan]

Previously, we introduce a ZRuntimePoolGuard to address the memory leak issue reported by valgrind.
But this doesn't cover the examples since we don't want to include them in our examples. Furthermore, users may abuse it like

#[tokio::main]
async fn main() {
    let _z = zenoh_runtime::ZRuntimePoolGuard;
    drop(_z); // Or something similar ways causing drop
    let pub_session = zenoh::open(Config::default()).res().await.unwrap(); // panic!
    ...
}

Instead, we can register a cleanup callback with libc::atexit. See this commit for the details.

[YuanYuYuan]

The minimal number of worker threads passing the CI test is 3 with additional 2 blocking threads for rare blocking events. https://github.com/eclipse-zenoh/zenoh/actions/runs/8658067718/job/23741242526

ZENOH_RUNTIME:

(
    rx: (handover: app),
    acc: (handover: app),
    net: (handover: app),
    app: (worker_threads: 2, max_blocking_threads: 1),
    tx: (worker_threads: 1, max_blocking_threads: 1),
)

[YuanYuYuan]

Configuration documentation is added.

[Mallets]

Would the path directive work once published on crates.io?
If we would need to publish the zenoh-runtime-derive crate, then the CI should be updated accordingly.

[YuanYuYuan]

I'm afraid that's needed. I prefer not to include them in the existing zenoh-macro to avoid polluting the library. What do you think? @Mallets

[Mallets]

I'm not sure to understand what's needed. Is publishing to crates.io needed or path = "..."?

[YuanYuYuan]

Needed to publish to crates.io.

[Mallets]

Then I would suggest to use zenoh-macros if possible. Adding a new crate only for this would require also to update the release CI. But first the crate should be reserved to crates.io and ownership shared with Eclipse.

[YuanYuYuan]

Okay. Let me handle this.

[YuanYuYuan]

Completed via db78a5a.

[YuanYuYuan]

After introducing the new maco14 runner, the default worker threads to pass the CI seem to change. Need to do more investigation.

[YuanYuYuan]

According to the action logs, all of these combinations are troublesome, which means rx must be greater or equal to 2.

╭─────┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───┬───╮
│ tx  │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 2 │ 2 │ 2 │ 2 │ 2 │ 2 │ 2 │ 2 │
│ rx  │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │ 1 │
│ app │ 1 │ 1 │ 1 │ 2 │ 2 │ 2 │ 2 │ 1 │ 1 │ 1 │ 1 │ 2 │ 2 │ 2 │ 2 │
│ acc │ 1 │ 2 │ 2 │ 1 │ 1 │ 2 │ 2 │ 1 │ 1 │ 2 │ 2 │ 1 │ 1 │ 2 │ 2 │
│ net │ 1 │ 1 │ 2 │ 1 │ 2 │ 1 │ 2 │ 1 │ 2 │ 1 │ 2 │ 1 │ 2 │ 1 │ 2 │
╰─────┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───┴───╯

[YuanYuYuan]

Combining the obervations of #893 (comment) and 036364f, the minimal worker threads to pass the CI are 5 + 3

ZENOH_RUNTIME

(
  rx: (worker_threads: 2, max_blocking_threads: 1),
  acc: (handover: app),
  net: (handover: app),
  app: (worker_threads: 2, max_blocking_threads: 1),
  tx: (worker_threads: 1, max_blocking_threads: 1)
)