When one use Monolog in a long process like an AMQP worker with a
`FingersCrossedHandler` or `BufferHandler` there is a drawback: as soon as there
is an AMQP message that generate a log >= error (for example), all next AMQP
messages will output logs, even if theses messages don't generate log where
level >= error.
In the same context there is a drawback for processor that add an UUID to the
logs. The UUID should change for each AMQP messages.
---
This patch address this issue with a new interface: `ResettableInterface` interface.
Side note: `reset()`, `flush()`, `clear()`, are already used in Monolog. So
basically, one can use the `reset()` on the `Logger` and on some
`Handler`s / `Processor`s.
It's especially useful for
* the `FingersCrossedHandler`: it `close()` the buffer, then it `clear()` the buffer.
* the `BufferHandler`: it `flush()` the buffer, then it `clear()` the buffer.
* the `UidProcessor`: it renew the `uid`.
* PHP Versions less than 5.3.6 throws undefined constant DEBUG_BACKTRACE_IGNORE_ARGS
Notice: Use of undefined constant DEBUG_BACKTRACE_IGNORE_ARGS - assumed 'DEBUG_BACKTRACE_IGNORE_ARGS' in /vendor/monolog/monolog/src/Monolog/Processor/IntrospectionProcessor.php on line 58
* Define DEBUG_BACKTRACE_IGNORE_ARGS if not defined.
* Solution using PHP_VERSION_ID and not defining...
...DEBUG_BACKTRACE_IGNORE_ARGS
* Handle DateTime objects in formatted meessages
* Use interface to catch both DateTime and DateTimeImmutable
* Maintain formatting standards.
* Visibility to private.
Since the code does not need neither the 'object' not 'args' keys from backtrace, we can save some memory by not requesting them.
I have a better idea planned too: first attempt getting the trace with limited back trace (limit to only about 5 results), and get the full one only if those were not enough
