Make schedule_event handle relative time instead of aboslute time

To make the event queue not dependent on time shifts, like some
operator sets the system clock, the event queue needs to be converted
to use a monotonic clock. To prepare for that conversion, we should
remove the usage of absolute time in the event queue API.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Make check module use callback events for hosts and service checks

The checks.c file used quite nasty interface for the event module,
tweaking raw parameters in the timed_event struct, which should be an
opaque type for the events.c module.

Let checks.c take over the functionality of lot of host/service check
specific filters in the events.c module, use callback events, but still
some event-time access is done. This does however mean that the
events.c can start getting refactored to remove lot of event-type
specific logic.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Convert event in xpddefault to schedule_event call

The xpddefault already used callbacks for events, those callbacks had
incorrect prototypes. The expected no arguments, but returned a status
code. The callback for event module expected one argument (void * with
storage), and no return value. So make it match.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Remove schedule_new_event and event_types all togheter

schedule_new_event is the last part that handled wall time in the event
queue interface (expect reading directly from the timed_event
structure, damn checks.c), which means we should remove it, if we want
to use a monotonic clock instead of wall time for the event queue.

Using a monotonic clock will make the time-skip-detection-function from
stone age totally irrelevant.

But we're not there yet... Check exeuction needs to be rewritten a bit
before, so it doesn't need to read time from the event, and probably
also not use wall-time for check exeuction logic.

This will however also break the API used in some modules for executing
timed event. Those modules should be updated to schedule_event anyway.
A wrapper for schedule_new_event, that uses schedule_event as a backend
would be useful if backward compatibility is expected.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Split up checks.c to hosts and service check modules

Hosts and services behaves quite similar, and should be treated
equally, and by the same methods. But they don't, so don't pretend to
be the same module.

Splitting up hosts checking and service checking in different files
makes it much easier to graps one module at the same time, so we can
refactor the scheduling of one module at the time to.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Move check logic from utils.c to checks.c

There where "utils" in utils.c to handle checks, which was just only
check logic. Those should be part of the checks module, so we don't
have a dependency from utils.c to checks.c/h

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
checks: Dont expose more methods than nessecary

We want to refactor the check module, so don't expose more methods than
nessecary.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Move handling of orphancheck to service/host check module

To reduce the nubmer of exposed methods, and keep modules isolated,
move handling of service and host orphan checking seperate, and
isolated within the modules, as seperate events.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
checks_host: Merge methods

a() { do_stuff; b(); } b() { do_other_stuff; } can simply be replaced
with a() { do_stuff; do_other_stuff; }, when that's the only call to b()

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Remove t-tap/test_events.c - this is old

This can't really been executed since nagios 3, since it uses really
really old prototypes of the reschedule_event-method (using head and
tail indicating the old linked list structure). The event queue is up
for rewriting to use monotonic time, and this file is just messing with
autocompletion in the IDE with all the stub methods.

Removing this is no loss but some gain.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Refactor host check event lifecycle

Since we don't want to forget checks by strange reasons, we should make
sure the event stays alive. That can be achieved easiest by making a
recurring event (an event that directly reschedules itself), which then
triggers an reexecution of the check.

Earlier, the next event was rescheduled first after the check result
was in, making it quite unreliable, if some exceptional case were
reached during check execution.

Signed-off-by: Max Sikstrom <msikstrom@op5.com>