throttle: fix TTL issue with redis-script based throttles

When using throttles with a long period, a porting issue from the JS
based throttle code meant that we'd compute a TTL in *seconds* but tell
redis that its value is in *milliseconds*, resulting in a much shorter
expiration time than desired, allowing more messages to pass the
throttling condition.

This issue doesn't apply to the redis-cell based throttle
implementation.

The fix here is simply to switch the `PX` (TTL in milliseconds) to
`EX` (TTL in seconds).

Possibly this was the source of the flakeyness that we could never
run down in https://github.com/KumoCorp/kumomta/issues/297

crates/throttle/src/throttle.rs

@@ -60,7 +60,7 @@ else
   throttled = 0
   reset_after = math.ceil(new_tat - now)
   retry_after = 0
-  redis.call("SET", key, new_tat, "PX", reset_after)
+  redis.call("SET", key, new_tat, "EX", reset_after)
 end
 
 return {throttled, remaining, reset_after, retry_after, tostring(diff), tostring(interval)}

docs/changelog/main.md

@@ -112,3 +112,5 @@
 * Rebuilding a MIME message (such as via `msg:check_fix_conformance`) that had
   binary attachments would incorrectly re-interpret the bytes as windows-1252
   encoded characters, damaging the attachment.
+* Using redis-based throttles without redis-cell and with long periods (eg: `500/d`)
+  could result in throttles being exceeded.