When a cronjob receives a TIME_SYNC event (because the system clock has
changed/drifted and the cronjobs are expected to recalculate their next
run slot) it should also clear the event.
Otherwise, the next `wait` will be skipped and the cronjob will be
executed even if it wasn't scheduled.
If may happen (usually because of a race condition) that a cronjob has
already been started, but it hasn't yet changed its status from IDLE to
RUNNING when the scheduler checks it.
This fix guards the application against such events. If they occur, we
should just report them and move on, not terminate the whole scheduler.
The cron scheduler has been made more robust against changes in the
system clock (caused by e.g. DST changes, NTP syncs or manual setting).
A more granular management for cronjob events has been introduced, now
supporting a `TIME_SYNC` event besides the usual `STOP`. When the cron
scheduler detects a system clock drift (i.e. the timestamp offset before
and after a blocking wait is >1 sec) then all the cronjobs are notified
and forced to refresh their state.
- Refactored the logic for executing a request and wrapping the response common to procedures, crons and event hook decorators into platypush.common.exec_wrapper
- Added mock getvalue() method to Logger to prevent PyCharm failures in the tests when sys.stdout is redirected to the Logger object
