Review representation of mask in Event

[hannobraun]

From reading the man pages, I get the impression that distinct event objects are generated for each type of event, and that therefore most bits in the event mask can't coexist. If that is the case, maybe it makes sense to create a new enum, EventKind, to represent the type of event.

One exception to this case is IN_ISDIR, which can be set in addition to other bits that identify the type of event. A new bool field could be created specifically for this flag.

In any case, before anything like this can be merged, more careful reading of the man pages and probably some experimentation is required.

[hannobraun]

I just had this thought regarding this issue:
The current test suite covers the basics, assuming that anything not explicitely covered will work fine, since we don't do anything fance that's specific to the type of event. Before implementing this issue, we should have a full test suite in place that covers all types of events, to make sure all our assumptions are correct.

Extending the test suite in such a way would be a good idea anyway, but it would be especially important before we hardcode any assumptions about how the event mask is structured.

[hannobraun]

Another tought:
I think it would be better to model event queue overflows as an error, not just another kind of event.

[hannobraun]

Additional thoughts:

• The cookie could be removed. Instead it could be added as a field to the rename event variants of the EventKind enum. Then an Eq implementation or a dedicated method could be used to determine whether the rename events match.
• IN_IGNORED events could be made more explicit. Right now they're just another kind of event.

[lefuturiste]

I would like to have a representation of an Event as enums to replace the EventMask, it would simplify using match patterns.