RateLimiter - consider whole operation execution time

[Kamil-Lontkowski]

Closes #246

[Kamil-Lontkowski]

Considering comment.

DurationRateLimiterAlgorithm.FixedWindow tracks number of running operations and doesn't replenish number of permits that running operations are "blocking".

DurationRateLimiterAlgorithm.SlidingWindow adds entry to log only after the operation is finished. This means that we consider end of operation as a point where we can replenish permits after per passes.

These changes mean that fixed window behaves in example as specified in the comment.

For sliding window consider this example:
We have three types of operations - instant, short(300 millis), long (3 seconds)

val rateLimiter = RateLimiter.slidingWindow(3, FiniteDuration(1, "second"), OperationDuration)

forkUserDiscard:
  result1 = rateLimiter.runOrDrop(short)
forkUserDiscard:
  result2 = rateLimiter.runOrDrop(short)
forkUserDiscard:
  result3 = rateLimiter.runOrDrop(long)
forkUserDiscard:
  sleep(1500.millis)
  result4 = rateLimiter.runOrDrop(instant)
  result5 = rateLimiter.runOrDrop(instant)
  result6 = rateLimiter.runOrDrop(instant)

After 1.5 second, two of three operations ended(at 0.3 seconds, so one full second passed since then), so we should have 2 available permits. Since at this point long operation is still running, we drop last operation and result6 is None.

Regarding leakyBucket. I don't know if it makes sense in this mode. It can work like fixed window, where we don't replenish tokens if operation is running, but I can't really wrap my head around if it makes sense.

[adamw]

@Kamil-Lontkowski thanks, this looks much better. I left some comments - I think it's especially worthwhile describing how the modified algorithms work (for our future selves :) ), and how they differ from the other mode counterparts.

[adamw]

And yes, I think the token bucket only makes sense in the original mode

Missclick

[adamw]

Thanks! :)