Implement severity calculation

[Thomas-Gelf]

We want to agree on a "severity" property and it's calculation. It is a bit set composed of current stat and various flags indicating whether and how the problem is "handled". An object can be handled by being acknowledged, in downtime or a service belonging to a problem host. Currently there are multiple slightly distinct implementations for this (Web 2, Businessprocess, IcingaDB prototype).

This "severity" should look the same everywhere, provided out of the box by Icinga and available as a dedicated field in the database and potentially for every kind of feature and/or interface. Our current prototype has

• a state mapping: down/critical > unknown > warning > pending > ok
• flags: none > acknowledged > downtime > no flag

Flags currently do not respect "host problem", so at least for services this should read:

• flags: none > service with host problem > acknowledged > downtime > no flag

We might evaluate whether the "unreachable" flag introduced with Icinga 2 should become a separate flag. Depending on the number of flags, state is left-shifted by a specific number of bits.

Last note: pending is currently state 99 for historic reasons. This has no direct influence on state calculation as the sort order is indexed completely different, but it would be nice to have a lower consistent number throughout all backends once we implemented this feature.

[dnsmichi]

We should consider reserving bits for future use. For example reachability, unhandled hosts, or anything else which might break if we change the bit masks.

[dnsmichi]

Pushed to master, please test.

Simple query with Paw.

curl -X "POST" "https://localhost:5665/v1/objects/services" \
     -H "X-HTTP-Method-Override: GET" \
     -H "Content-Type: text/plain; charset=utf-8" \
     -H "Accept: application/json" \
     -u root:icinga \
     -d $'{
  "filter": "service.severity > 4",
  "attrs": [
    "severity"
  ]
}'