mitigate memory leak in http client due to unreliable lazy parameter spec

[Boris-Barboris]

When http client is used heavily with high probability of failed requests (400 response from the remote server is sufficient in my case), VIRT/RSS of the vibe-d server process raises infinitely under dmd 2.083, even when loglevel is not debug. Two things are obvious from Heaptrack traces:

1. logDebug's second parameter is not lazified.
2. e.toString().sanitize() leaks memory.

[s-ludwig]

I've taken a look at the logging code and it seems like vibe-d/vibe-core#e769a9b1ca8076e4aeceb573c86140a950f9cf8f has introduced a regression w.r.t. lazy evaluation of the format arguments. Instead of always making a copy of the arguments, it should first check if any logger actually has the required minLevel. I'll open a PR there to fix this at its root!

sanitize() shouldn't leak memory per se (and should only allocate if there is actually anything to sanitize), but I guess that this is an instance of the GC not being able to reuse pool memory (maybe due to memory fragmentation, or maybe due to a bug). I've observed that lots of times in the past in situation where memory was being allocated rapidly from multiple threads.

In any case, this is a good catch!