Support other notification types

[julianbrost]

At the moment, pretty much only state notifications are sent. We also have to allow sending other notifications.

For example, in case of Icinga 2, the available notification types are:

• DowntimeStart
• DowntimeEnd
• DowntimeRemoved
• Custom
• Acknowledgement
• Problem
• Recovery
• FlappingStart
• FlappingEnd

Also, there are events within an incident that could be worth an extra notification, for example:

• Incident (un)managed / manager(s) changed
• Incident escalated

Suggestion for moving forward (1. should be pretty straight forward, the others probably need a bit more discussion about the details)

• [x] Just send all of these non-state notifications to all incident recipients. As the very first step without any new configuration options. If there's an open incident, it sounds like a reasonable default to get notified about everything that's related to the incident if someone is involved in the incident.
• [ ] It should also be possible to receive those notifications without an incident. For this, an option would be to have something like second part in the rules next to (on a logical level, not on the representation in the rule editor) the escalations where one can configure which event types should be routed to which recipients.
• [ ] There should probably be the possibility to limit the types from 1., maybe with something like allowing to exclude certain types in the event rule per recipient.

[yhabteab]

Currently, the following rough idea exists: In event rules, the escalation stages get an extra option to restrict notification types

Don't we also want to allow to restrict notifications at contacts level, just like in Icinga 2?

[julianbrost]

Not for now, but quite possibly at a later stage, similar to per-contact time restrictions for example.

[julianbrost]

@nilmerg I've updated the issue description after our discussion today. Please have a look.

[nilmerg]

Looks fine