Message filtering logging is unhelpful

[Phil Connell]

The standard rate-limiting plugin defines always-on filters for sending and receiving messages. These filters (almost) always filter out the messages, to queue them up and send (if the sender/recipient isn't being ratelimited).

This means that logs of this form are very common:

2014-08-12 12:02:45 INFO Sending message to j@i.d
2014-08-12 12:02:45 INFO Filtered out message to j@i.d
2014-08-12 12:02:45 INFO Sending message to j@i.d
2014-08-12 12:02:45 INFO Filtered out message to j@i.d
2014-08-12 12:02:45 INFO Sending message to j@i.d
2014-08-12 12:02:45 INFO Filtered out message to j@i.d

There are a couple of problems with this:
 - 'Filtered out message' is a bit misleading (although accurate from the core's point of view).
 - There's no indication of *why* the message is filtered.

The 'filtered out' log should be updated to indicate the filter callback that caused the message to be filtered

[Phil Connell (pconnell)]

Alternatively, it would be good to rework the ratelimit plugin such that it doesn't filter messages that it is allowing to be sent.

This may need more integration into the core message handling.

[ChrisD (gingerchris)]

Reduced filtering logging to debug.
It's the responsibility of filters to debug info on why they are filtering.
In ratelimit's case as it's not actually filtering the message there's nothing to add.

There maybe better ways to solve this, happy to have wishlist or blueprint items for them