access to the Linux-like ratelimiter was not properly synchronized, and
the system rate-limiter was not using it in any case.
This could lead to the rate-limit settings not being properly
respected, but no "hard error".
(for example, it did not work with imdup). The reason was that
the PRI value was used, but that needed parsing of the message, which
was done too late.
and make imjournal use it.
The new mode is needed, as imjournal uses journal's timestamp
as message generation time (which otherwise is when the message
entered the system, and the ratelimiter uses this as current
timestamp in order to save performance).
It is debatable if imjournal is doing the right thing here. But
it doesn't feel totally wrong. So let's safe that debate for
later ;)
The message that reports how many messages were lost due to
ratelimiting was sent before reseting the state that led to it. If it
itself got ratelimited, this could lead to an endless loop.
If messages are being dropped because of ratelimiting, an internal
message is generated to inform about this fact. This should happen
only uppon the firs occurance but the counter that tracks the number
of dropped messages was incremented only after sending the message. If
the message itself gets ratelimited, an endless loop spins out of
control. Thanks to Jerry James for notifying about this.
Move the severity-check logic inside the ratelimiter and add a new
function ratelimitSetSeverity() to manipulate the treshold.
Currently only utilized by the imuxsock module.
