Mixing @match methods and 'state' in event_types drops state events

[Max Rabkin]

If a Processor has event_types = ('message', 'state'), and has an @match method, then event dispatch raises a KeyError on state events, so they never get handled.

If one loads the attached 'bug' plugin, and says "$botname: bug", the bot correctly replies "You said 'bug'", but if a state event occurs, the bot does nothing and the following appears in the log:

DEBUG source.[***]: [***] has online [***]
DEBUG core.dispatcher: Received event from [***] source
ERROR core.dispatcher: Exception occured in Bug processor of bug plugin
Traceback (most recent call last):
  File "/home/max/ibid/ibid/core.py", line 25, in _process
    processor.process(event)
  File "/home/max/ibid/ibid/plugins/__init__.py", line 57, in process
    if match is not None:
  File "/home/max/ibid/ibid/event.py", line 15, in __getattr__
    return self[name]
KeyError: 'message'

The problem seems to be the way patterns are matched in Processor.process

[Michael Gorven (mgorven)]

Processors weren't designed to handle multiple event types. Previously one
could only specify one event type, but this was changed recently in order to
support NOTICEs. If you need to handle multiple event types you can either
use multiple Processors in a plugin, or override process() and do it
manually. I'm therefore inclined to wontfix this.

[Jonathan Hitchcock (vhata)]

There's no reason why Processors *shouldn't* handle multiple event types. You shouldn't have to make multiple Processors if they're all going to do the exact same thing, just because our buggy handler code doesn't support it. And you certainly shouldn't have to override process() - we're supposed to make things easy.

We should look at what event_types, @match, and @handler "mean" (in English), and make them behave that way, without vomiting exceptions at our authors, as above. Even if we want to force them not to do things like Max is doing in bug.py, we should at least error at them quietly, yes?