fix listening to RUST_LOG

[StripedMonkey]

Per the logger documentation:

Enables the user to choose log level by setting RUST_LOG= environment variable. This will use the default level set by with_level if RUST_LOG is not set or can't be parsed as a standard log level.
This must be called after with_level. If called before with_level, it will have no effect.

Personally, I feel that using a config file, which defaults to false to configure whether or not to listen to the environment for enabling and disabling logging is a bit dumb. Usually environment variables are meant to allow you to modify the configuration of a program for one "environment", not necessarily permanently. Especially when you get more complicated environment filtering.

For me, I'm content with Info or even Debug as the default, but will occasionally bump the log level to tracing for specific sessions. That's not something I want to make a permanent change, so I execute the program as RUST_LOG=tracing cargo run instead of having to go into a file and modify it, then undo the change later. The fact that you can't do this by default is counter-intuitive.

Although I'm sure there are better sources for it, I personally believe that this stackoverflow sums up my experience and feelings around precedence

Additionally, I'd like to use this as a springboard to advocate for a few things, primarily introducing the idea of migrating away from log to tracing, as there's a lot more that can be done with regards to performance measuring and testing.

[Snowiiii]

Hey @StripedMonkey, Already a while since your last PR :D. Yep seems like i missed the env configuration when setting this up with the config.

I was thinking about using tracing to better track performance, but I'm not completely sure about this my main concerns are:

1. Performance regression, I'm pretty sure tracing will impact the performance more than the current log implementation, In debug this is may Okay but especially in an production/release build this may makes performance worse
2. The second problem would be that we don't always need to trace, Often we just want to print out a simple message, maybe something like "Failed to handle Packet ....".

[StripedMonkey]

Tracing is log compatible, and provides error!() macros that behave the same as log ones. As a general rule tracing is not particularly costly performance wise, and you can always pull logging out of hot paths if it's a big deal (you'd want to do that regardless.

If it's particularly an issue, it's possible to enable and disable logging levels at compile time if you want to get rid of things for release builds.

[Snowiiii]

Tracing is log compatible, and provides error!() macros that behave the same as log ones. As a general rule tracing is not particularly costly performance wise, and you can always pull logging out of hot paths if it's a big deal (you'd want to do that regardless.

If it's particularly an issue, it's possible to enable and disable logging levels at compile time if you want to get rid of things for release builds.

Sounds fine, If you want you can may make a PR to move to tracing