Fix SlidingTimeWindowReservoir trim operation after overflow

[ho3rexqj]

The existing trim operation in SlidingTimeWindowReservoir assumes that values returned by getTick are strictly increasing. When the result returned by getTick overflows, the trim operation will behave improperly - trim operations just after the overflow event will likely clear values within the current window, and trim operations well past the overflow event will likely fail to clear updates outside the current window (updates added before the overflow event).

To illustrate this behavior consider a reservoir with an 8-bit value returned by getTick, a window size of 2, and ignore the trim operations effect on the tick count:

update @123: 1
update @124: 2
update @125: 3
update @126: 4
update @127: 5
trim @127 - clears values before @125 (1, 2)
update @-128: 6
trim @-128 - clears values before @126 (3, 6) - 6 cleared improperly
update @-127: 7
update @-126: 8
trim @-126 - clears values before @-128 (none) - 4,5 "leaked"

The proposed fix properly clears any values in the reservoir outside of the sliding time window. For the purposes of that operation, the start of the time window is defined as now-window, and the end of the time window is defined as now+CLEAR_BUFFER, where now is the value returned by getTick at the start of the trim operation. This prevents trim from improperly clearing updates added concurrently while the operation is underway.

[arteam]

Thank you very much for the very detailed write-up and the overflow test!