Reduce likelihood of a race between rules evaluation and alerts scheduling

[marccarre]

Identified by @bboreham, all credits go to him 👍 -- #482.

This is a quick change to (hopefully) help identify an issue with alerts periodically going back to pending, and not firing; and reduce the likelihood of the race condition interfering with this investigation.

Alternatives considered:

• add half-an-interval to, but this would still lead to a race 50% of the time,
• add one second, but this would still lead to a race every 15 seconds (the current default interval),
• randomise, but could actually make it harder to identify issues,
• add 10 ms (current state): this should be long enough to avoid a race condition, and short enough to maximise the time before the two schedules overlap again (if the race is happening 100% of the time every 15 seconds, then, with 10 ms offset, it would only happen 1/1500 of the time).

Note that the first interval is used by a timer, and the second in a Defer instruction, so one would think the execution of the scheduled work would add enough noise to avoid races (?).

A proper fix and the implementation of TODO: Separate configuration for polling interval. should follow, once the incident is resolved.