Service#GetSeverity(): behave as the respective IDO query of Icinga Web

[Al2Klimov]

which doesn't include host reachability.

W/o this #9154 would still miss severity updates as it doesn't take host reachability into account.

[julianbrost]

In terms of adjusting behavior to the corresponding query in the IDO monitoring module: only difference left seems to be the cases where it adds 1/2/4. This is the case when the service is OK but acknowledged (Is that even possible?) or in a downtime (Makes a small difference whether OK services are sorted by downtime state or not. Neither the monitoring nor the icingadb module seem to render OK services any different based on whether they are in a downtime or not).

History lesson:

• March/April 2017: Prototyping for Icinga DB done on the master branch (Implement severity calculation #5117)
• June 2017: Most of the protype removed for the 2.7 release (Remove experimental redis feature before 2.7 release #5369), severity remains
• June 2019: severity is documented (Docs: Add new runtime checkable attributes and explain severity in tech concepts #7233), released in 2.11
• November 2019: behavior of severity is changed (037357a, Add IcingaDB #7601), released in 2.12

Service::GetSeverity() is only used by the Icinga DB code at the moment. However, it's also exposed through the API and in the DSL, so the change is visible to the outside world. This also somewhat touches #9130, so I think we should come to a conclusion what we want to do there before doing this change here. Currently it seems like the existing severity value changes into some kind of opaque value that should be documented something like "the internal structure of this value may change, it should only be used for comparisons/sorting".

In general, I'm fine with this change if this means that we'll use and document the severity as suggested. I think this is the only sane option for a value that's intended to be used as a sort order, as otherwise, this might prevent us from tweaking the sort order without either breaking compatibility again or adding a new value that works as described. For #9130, we can additionally discuss if we want an additional bitset combining all state flags with a defined internal structure.

@lippserd Please approve the change considering this summary.

@Al2Klimov Please add some reference to the reachability/severity PR to the description and how this is done due to that PR.

[lippserd]

we'll use and document the severity as suggested. I think this is the only sane option for a value that's intended to be used as a sort order, as otherwise, this might prevent us from tweaking the sort order without either breaking compatibility again or adding a new value that works as described. For #9130, we can additionally discuss if we want an additional bitset combining all state flags with a defined internal structure.

That sounds good!