Replace logging layer with tracing

[Keksoj]

For now, Sōzu implements its own two layers of logging :

• a set of logging macros (info!, debug!, etc)
• a Logger instantiated in each worker to gather the log events and write them onto 5 possible targets:
  • a UDP address
  • a TCP address
  • a unix socket
  • a file
  • stdout

Since the birth of Sōzu, the tokio ecosystem has grown to become a defining standard in terms of asynchronous software architecture. It contains its own tracing crate, tracing, compatible with a number of loggers.

Switching Sōzu's home-made macros and logger will allow for a lot of enhancements down the way (such as structured logging: #437) and remove a great deal of code that is uneasy to maintain.

This PR aims to perform a drop-in replacement of Sōzu's logging logic, including notably:

• a naive use of logging-subscriber to print logs to stdout throughout Sōzu
• the ability to change the log level during runtime
• send logs to all 5 targets (udp, tcp, unix socket, file, stdout)

[Geal]

sorry, I have to be annoying again and ask you to think about why the code is written that way instead of quickly replacing it.
The custom logging in sozu is not there due to a lack of libraries for that, they existed long ago. That is because logging is an extremely costly task.
At first, the proxy used the crates log and env-logger. Adding a custom formatter with env-logger destroyed the performance, so I had to vendor the macros and make custom formatting faster https://github.com/sozu-proxy/sozu/blob/main/command/src/logging.rs#L568
Logging was still about 40% of CPU time so I went and optimized it further:

• RFC3339 formatter without unneeded allocations
• separating access logs to send them to another backend
• buffering file writes, taking into account that we need to write full lines in one syscall because multiple workers would write to the same file
• vendoring the log filter parsing because that was just executing way too often (it is better in tracing now, but still not great)

A HTTP proxy is not doing much: reading data into a buffer, parsing it, writing data from a buffer to a socket. So it's not a surprise that tasks like logging and metrics, that can result in a lot of small allocations in the hot path, would be costly.
BTW I'm pretty sure we'll be back on the same topic in a few months when you discover the custom statsd metrics writer that, like logging, was painstakingly written for better performance and avoiding very annoying bugs.

My advice here:

• I'm not saying tracing is bad, it's actually great and solves a lot of problems, but,
• do not go and replace the logging code without benchmarking it, because it will flush years of effort on performance down the drain (like recently when I had to call out a PR that introduced way too many allocations)
• get into the habit of benchmarking. It's easy to assume that Rust is fast enough and sozu alady has a good foundation fr performance, but it actually requires a lot of care. Be indful about the kind of benchmark you run, and the parameters (example: you should reduce the resources given to sozu to a minimum while giving a lot of resources to the backends, otherwise you're testing the backend's performance, not sozu's)
• remember Chesterton's fence

[Keksoj]

Thanks a lot for your advice @Geal , we did miss the sign on that one. As @Wonshtrum suggests, these performance issues may arise as well with the use of anyhow for error management in the Sōzu lib, as it allocates memory on the heap, and errors are quite frequent when connecting to backend for instance.

Your remark put emphasis on benchmarking and that's what we should focus on. We'll definitely look in this direction. Thanks!