In the default case of a period being 60 and the evalation period being 60, the
window was being alternately slid 0 slots and then 2 slots. This caused it to
reject some recent measurements.
To illustrate what was happening, assume a SlidingWindow with a period of 60, and
a viewEndTimestamp of 60, and the AlarmDelay default of 30 seconds. AlarmDelay is
used to increase the likliehood a metric arrives before the window is evaluated.
Also assume the evaluation period is happening at 20 seconds after every minute.
On the first one, at time 20, the time is not past the viewEndTimeStamp so nothing
happens. On the second one, at time 80, the time is past the viewEndTimeStamp but
the window doesn't slide because the time has be > viewEndTimestamp + alarmDelay.
At time 140, time is > viewEndTimestamp + alarmDelay so the window is slid. However,
since the alarmDelay wasn't being accounted for in the number of slots to slide, it
was sliding it one too far. On the next period it wouldn't slide at all and then
the next one it would do two again.
This was fixed by accounting for alarmDelay when calculating the number of slots to
slide
Change-Id: I4fcfd41f2de515684b3d0054f9c46c925ee4807b
fd5c41d720