Add optional tracing feature for development logging

[Notgnoshi]

This PR adds optional tracing instrumentation in the ag_iso_stack::tracing module to enable tracing, if the tracing feature is enabled. Otherwise, the macros provided by the ag_iso_stack::tracing module compile away.

I expect this to be a helpful developer feature, that I don't expect a user to want to use. I also expect that as AgIsoStack-rs grows, we'd probably want to remove the tracing::trace! macros in the Drivers.

[codecov]

Codecov Report

Attention: 17 lines in your changes are missing coverage. Please review.

Comparison is base (da74b03) 11.52% compared to head (0160334) 10.89%.

Files	Patch %	Lines
src/driver/socketcan.rs	0.00%	17 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #12      +/-   ##
==========================================
- Coverage   11.52%   10.89%   -0.63%     
==========================================
  Files          17       17              
  Lines        2664     2624      -40     
==========================================
- Hits          307      286      -21     
+ Misses       2357     2338      -19     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JannesBrands]

Like a lot your optional tracing feature. But is the intention to use it only on the can driver layer or also for network management and other stuff? Would like to use it in all the library cause it helps also a lot to debug in the field. Another idea would be to have a possibility to activate it manually for single parts of the library. Cause with all that bus traffic the console would be a complete mess. For example to just trace the 11783-6 or only the network management...

[Notgnoshi]

But is the intention to use it only on the can driver layer or also for network management and other stuff?

I intend to use it anywhere it's useful!

Another idea would be to have a possibility to activate it manually for single parts of the library.

Yeah, this would be awesome - but I'm not quite sure how to do that right now. I think for now it can be enabled/disabled globally until it becomes a problem?

Cause with all that bus traffic the console would be a complete mess.

Yes it would be 😆 - my original plan when I started this was to add it during development of a feature, and then remove it once I'm confident that feature works, but I like your idea of enabling it for different parts of the library more ❤️

[JannesBrands]

Yes it would be 😆 - my original plan when I started this was to add it during development of a feature, and then remove it once I'm confident that feature works, but I like your idea of enabling it for different parts of the library more ❤️

I would like to have a custom tracing for each module/folder like in #26 where it prints for example: network_management: lipsem ido dasdoaisdn or some stuff like that. So you can activate and deactivate it for each module. Especially in field you dont know sometimes if it is the fault of the other ecu for something like a missing address claim or if its the own ecu with our library. With that library it would be easy to verify without doing a can trace. Especially things like the state of any state machine you cannot see inside the cantrace. Then it is so much more easy to identify a bug inside our code or who is causing the problem. Lets keep that idea in mind when #26 got merged.

[Notgnoshi]

I would like to have a custom tracing for each module/folder like in #26 where it prints for example: network_management: lipsem ido dasdoaisdn or some stuff like that. So you can activate and deactivate it for each module.

I agree - I made #31 for this.