Switch to custom logging macros to avoid deadlocks

[Yadunund]

Address logging related deadlock discovered in #182.

@clalancette I went with a more C++ implementation here by relying on the popular fmt library which is apparently more performant than printf and ostringstream . Let me know if you prefer following rcutils/logging.h type of implementation with a specifiable allocator. We could also directly invoke rcutils_logging_console_output_handler.

[clalancette]

@clalancette I went with a more C++ implementation here by relying on the popular fmt library which is apparently more performant than printf and ostringstream

The problem with bringing in this dependency is that we'll have to deal with it on Windows. Also, in general, the more dependencies this has, the harder it will be to get rmw_zenoh into the core. Finally, my understanding is that either C++-20 or C++-23 will have this directly, so we can get this "for free" when we upgrade in the future. For all of those reasons, I think we should stick with printf-style logging for now.

We could also directly invoke rcutils_logging_console_output_handler.

That's a really good idea, I'd prefer that. While it won't get us all of the features of the rcutils logger, it will at least move us in that direction.

[Yadunund]

Thanks for the quick feedback! I'll update to rely on rcutils functions.

[Yadunund]

@clalancette I've updated accordingly.

I've ran the problematic case from #182 several times and it works most of the time*.

# terminal 1
ros2 run rclcpp_components component_container

# terminal 2
for i in {1..100}; do echo "ros2 component load --node-namespace /talker${i} /ComponentManager composition composition::Talker"; done | parallel

* once in a while, the command in terminal 2 does not exit cleanly. However running ros2 node list | wc -l returns 101 indicating that 100 nodes were indeed injected into the component container. All topics are also available. So perhaps the issue there is related to shutdown?

[clalancette]

Overall, this looks great! I've left a couple of pieces of minor feedback inline.

One other thing we might want to consider is adding a GitHub action here to check if a PR contains RCUTILS_LOG_*, or does #include <rcutils/logging_macros.h>. That would help ensure that we don't add these by accident in the future.

[clalancette]

This is fantastic! I'll note that the new check_logging.yaml job is currently failing, because of course this PR does contain RCUTILS_LOG macros (that we are removing). It would be nice if there was a diffDoesNotAdd configuration variable, but after this PR all further ones shouldn't have this problem. So I'm going ahead and approving this.