Fix: RedisTokenBucketRateLimiter does not refill and block randomly anymore

[Namoshek]

Fixes #46

This PR reworks the Lua script used by the RedisTokenBucketManager in a few ways. The primary goal is to fix the issues mentioned in #46. Summary of the changes:

• The current time now is generated by Redis now, which is safe due to the use of redis.replicate_commands(). By letting Redis take the time itself, all requests are clocked by the same system, guaranteeing best accuracy.
• All timestamps are in milliseconds now, which is more accurate and allows working with sub-second TimeSpans.
• redis.call('GET', ...) calls have been replaced with redis.call('MGET', ...) to safe a round-trip to the database.
• Some variables were renamed in order to give them a clearer name.
• The new current_tokens together with the timestamp are only persisted, if the request is allowed.
• The TTL for the persisted data is now calculated from the periods_until_full multiplied by the period (duration). This fixes the first issue described in The RedisTokenBucketRateLimiter refills the bucket immediately after some timeout #46.
• The persisted timestamp is not now anymore but the time_of_last_replenishment. This fixes the second issue described in The RedisTokenBucketRateLimiter refills the bucket immediately after some timeout #46.

Besides the changes to the Lua script, the PR also includes the following other changes:

• The parameters passed to Redis in IRedisDatabase.ScriptEvaluate() are now explicitly flagged as (RedisKey) or (RedisValue) respectively. This ensures that the parameters are mapped to the KEYS[] and ARGS[] arrays correctly, which is important for correct script execution (especially in clusters).
• The Lua script does now calculate retry_after (in milliseconds), which is 0 if the request was allowed or the milliseconds until the next token is generated if not allowed. This value is returned by the rate limiter in rounded up seconds.

[Namoshek]

The failed build is most likely due to the workflow not having access to the Redis connection string secret. The reason for this is explained in this GitHub blog post, where they describe that pull requests could potentially get access to secrets when using the pull_request workflow trigger type. If the pull_request_target workflow trigger type is used instead, the build runs against the build definition of the pull request target branch and secrets are made available automatically.

[cristipufu]

@Namoshek thanks for your contribution!