fix: remove zenoh_util from examples

[wyfo]

Users should not use zenoh_util::try_init_log_from_env. They should instead
register their own subscriber with their own formatting preferences.
Examples provides a basic logging initialization that users can copy-paste
if they don't want to learn tracing.

@Mallets @milyin @gabrik

[wyfo]

This PR is based on #1007, so it will be draft until its base is merged.

[Mallets]

I believe keeping something like zenoh::try_init_log_from_env() is a preferable approach.
I.e. to use zenoh crate instead of zenoh_util.
For normal user in with not-so-advanced use cases it's quicker and faster to get some log out of zenoh instead of:

1. Investigating which logging library needs to be used
2. Import it in its Cargo.toml
3. Write initialization code

I'd also prefer to keep something like zenoh::try_init_log_from_env() to have some consistency across programming languages. How an user would initialize logging from C, C++, Python, Java, and Kotlin bindings? If in any binding we expose a try_init_log_from_env() then it's easier for the user to just start the underlying logging system and get some more information from zenoh.

@milyin opinions?

[wyfo]

Bindings should try to bind zenoh logs to the language logging system, e.g. for Python redirect tracing events to a logging.Logger. This way, users will be able to control their logs, if they want for example to redirect them to a syslog instead of stderr.
For C, we could maybe provide a callback API, to be called for each log event, and a default API to print them to stderr. I just don't think only providing stderr log printing is enough, and certainly not for Python, where the logging library is part of the standard library.

My argument against zenoh::try_init_log_from_env is quite the same about not exposing a zenoh::main instead of tokio::main. I don't think it's too much work for user to copy-paste the initialization code from examples, but that's true there is an additional cargo add to be done. However, if the user wants to add logs in its own code, he will still have to install tracing himself.

The other issue was that try_init_log_from_env leaks memory, so this leak becomes the responsability of zenoh. Of course, it's a static variable not freed at the end of the program issue

[Mallets]

I think we are missing an important point here.
Many users do NOT care about logging in their system. They may not even be logging at all strictly speaking. They need a way to print at screen what's happening to debug the system. As of today, this can be easily done by setting RUST_LOG=debug as environment variable if try_init_log_from_env is called without the need to care about anything else.

You get zenoh, you get easily some output. I think we should keep this capability of easily do it from the user perspective.

[wyfo]

Ok, so I can close this PR. But my point about the bindings doesn't change: we should provide zenoh logs in a "native" way for the different bindings, at least for the Python one; C/C++ can wait users asking for it i guess.