Change schedule configuration to support new rotations

[julianbrost]

This is a fundamental and incompatible change to how schedules are defined. Now, a schedule consists of a list of rotations that's ordered by priority. Each rotation contains multiple members where each is either a contact or a contact group. Each member is linked to some timeperiod entries which defines when this member is active in the rotation.

This PR already includes code for a feature that was planned but is not yet possible using the web interface at the moment: multiple versions of the same rotation where the handoff time defines when a given version becomes active.

With this change, for the time being, the TimePeriod type itself fulfills no real purpose and the timeperiod entries are directly loaded as part of the schedule, bypassing the timeperiod loading code. However, there still is the plan to add standalone timeperiods in the future, thus the timeperiod code is kept.

More context for these changes:

• Icinga/icinga-notifications-web#177

• 193

The commits in this PR:

• 87a92b4d04a4bc5ffa9607646a6b3c86adeb4b59, 0fbbe5200608bcbcd28317601415eac28a713ebd: Some code improvements that prevent code duplication in following commits.
• 501ff1c6385061e175c7ba07a2ba35f0f279eb0b: Schema changes from #193 squashed into a single commit.
• b6f524ef7c929961f46ae0369c1a1a5cd993b0b8: I found the proposed upgrade script to be more complex and more destructive to my personal test data than necessary, thus I simplified it. Also, now it looks more in line with the other preexisting schema upgrades as well.
• 86d8e47d3d2e551be95f26e1c2cff3f044e7ead7: The main change of this PR, see general description above.
• 27c1180ed174ccc9323f704d1e440779e5539e43: Always explicitly call Init() on timeperiod entries and require this in other methods (as suggested in https://github.com/Icinga/icinga-notifications/pull/204#discussion_r1622606472).
• 83678ae29fd232e3cea79dc088910969f5ffc744: Add debug logging on how recipients were expanded and a warning if no contact was found like it may happen when a schedule has a gap (as suggested in https://github.com/Icinga/icinga-notifications/pull/204#pullrequestreview-2090414546).
• d47fde41171042dd9d7f096559d02eebabea15d1: Add a /dump-schedules debug endpoint that returns how all schedules expand within the next two days (as suggested in https://github.com/Icinga/icinga-notifications/pull/204#pullrequestreview-2090414546)

Dependencies

To allow testing with Icinga Notifications Web, the following PRs are required there:

• https://github.com/Icinga/icinga-notifications-web/pull/183
• https://github.com/Icinga/ipl-html/pull/137
• https://github.com/Icinga/ipl-web/pull/222
• https://github.com/Icinga/ipl-web/pull/223

[!CAUTION] Applying the schema upgrade is destructive to the current schedule configuration and there is no easy way to rollback. Be prepared for this and better create a backup first.

closes #193 (schema change already contained in this PR)

[julianbrost]

Force push just updated a comment in rotations.go and rebased. The latter looks a bit confusing in the diff view: I just renamed 025.sql to 026.sql but it shows the differences between the two different and unrelated versions of 025.sql.

[julianbrost]

Most new changes are within the three new additional commits (please see their commit messages and the updated PR description). Changes to to existing commits should only include changes necessary due to the rebase over #114 (changed import, more db:"-" needed) and the removal of the unnecessary explicit access of the embedded SugaredLogger (https://github.com/Icinga/icinga-notifications/pull/204#discussion_r1622602012).

[julianbrost]

Next step: coordinating merging of all the required PRs, that'll be fun.

[julianbrost]

Next step: coordinating merging of all the required PRs, that'll be fun.

That was surprisingly easy.