Right now, if an alarm fires exactly on time (within 1 second), or
exactly on a multiple of its period, statsd will reset the alarm for the
same time, which can result a loop of statsd setting an alarm, the alarm
firing, statsd setting an alarm at the same time, etc.
The fix is that if an alarm fires on time, we should move to the next
period.
Test: atest statsd_test (added to a test, which would fail without the
code change)
Bug: 159098080
Change-Id: I150538cb1d3d5a2b943df2a32d92f8f84bb96626
f5cd94b4d0