Any `get` call will further delay a positive `remaining` value

[newhouse]

Hello!

This line says to me that by calling the Limiter.prototype.get method, an entry will always be added during the computation of the the count, and more importantly, the returned remaining values.

In laymen's terms, it seems like the caller is "charged" a count value, even when ultimately the limiter willmay tell them that they have zero remaining. This can result in the goalpost continuing to move for an impolite/naive caller. This may be what we want, but it may not be. A poorly written caller script may end up perpetually waiting.

It would be nice if there were a way to only add the element to the array if remaining > 0.

I'm not a Redis expert, but I realize that the commands are issued within a MULTI transaction, and recognize the benefits there that it may not be a good idea to only perform the ZADD if we think there are "tokens" remaining (due to concurrency realities). Perhaps:

• Some crazy if/else can be done in the Redis commands that only calls ZADD if the ZCARD length was below the max?
• Maybe some of the ZADD options can support something useful with this idea?
• Perhaps if the result is that the remaining <= 0, then element added by ZADD is removed in a subsequent Redis command? We know the element we created, right? This may open the user up to slightly race-vulnerable conditions (or not) that they can decide if they are OK with?

Seems semi-related to:
#43
and
#45