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>
Rearrange service check methods for easier refactoring

Arrange the methods in the service check module, so they are grouped
according to scheduling, execution, processing and helpers

Signed-off-by: Max Sikstrom <msikstrom@op5.com>
Remove function call logging

Log function calls is basically what a debugger does, and lot more. If
someone wants to know which functions are called, use gdb and add a
breakpoint at the call. That can be done conditionally too, and
attributes can be inspected.

Removed by coccinelle script:

@@
expression LVL;
expression FMT;
expression list VALS;
@@

- log_debug_info(DEBUGL_FUNCTIONS, LVL, FMT, VALS);

Signed-off-by: Max Sikström <msikstrom@op5.com>
Refactor service check scheduling

Always reschedule a service check one check_interval in the future
directly at event handler execution. If we want something closer,
replace the event, so we can guarantee that one service check event is
scheduled at all time. If we can do that, we know for sure that we
don't forget about service checks.

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

That structure doesn't really contain any information nessecary for the
outside world. It contains a pointer to the callback, a storage for
user data, and a time, which doesn't really mean anything soon (when
we're going to monotonic time). Make it opaque to restrict the
temptation to read variables directly

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