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

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.