Incident muting & notification suppression

[yhabteab]

resolves #190

[yhabteab]

Have just rebased the PR to resolve the conflicts resulting from #114.

[yhabteab]

I have just rebased it and committed new changes separately 246f0f0.

[yhabteab]

Once again, I have found a bug where pending notifications, e.g. triggered by a downtime-start event, are not being sent ab7e482.

[julianbrost]

For the record: the recent changes pushed here should address something I discussed with @yhabteab yesterday: so far, the handling events like a downtime start without an incident was that if it was received from the Icinga 2 event stream, it would mute the object, which is also persisted in the database, but the event itself wouldn't make it to the database and result in an error. When catching up missed events, it wouldn't even mute the object if there was no incident.

[yhabteab]

There is still one annoying use case that I haven't been able to work around so far, and I don't know if it can be solved so easily.

• Acknowledging a host/service via the UI/API results in the author of the ACK-Set event being promoted to an Incident Manager.
• Click on unmanage Incident in the incident detail view
• Now restart either Icinga 2 or the Notifications daemon and the author will be promoted to an Incident Manager again.

[yhabteab]

Following yesterday's discussion, quite a lot of mysterious bugs began to appear, so the PR has been growing slowly. Please take another look!

[julianbrost]

@oxzi FYI: I don't expect further large changes to this PR, so feel free to have another look.

[oxzi]

Otherwise, I have successfully tested the PR and have not seen anything suspicious in the diff.