Handle concurrent calls

When multiple successive calls are made the next calls should not create again the rate limiter in Redis.

Successive calls to .limit were allowing requests when in fact they should not. Now the code uses `setnx` to handle the case when the key is created between the `mget` and the `create` call.

```
1394812740.666083 [0 10.0.2.2:61581] "MULTI"
1394812740.666115 [0 10.0.2.2:61581] "setnx" "limit:10:email:count" "1"
1394812740.666132 [0 10.0.2.2:61581] "setnx" "limit:10:email:reset" "1394812800"
1394812740.666148 [0 10.0.2.2:61581] "setnx" "limit:10:email:limit" "2"
1394812740.666162 [0 10.0.2.2:61581] "expire" "limit:10:email:count" "60"
1394812740.666179 [0 10.0.2.2:61581] "expire" "limit:10:email:limit" "60"
1394812740.666194 [0 10.0.2.2:61581] "expire" "limit:10:email:reset" "60"
1394812740.666210 [0 10.0.2.2:61581] "EXEC"
1394812740.666567 [0 10.0.2.2:61581] "MULTI"
1394812740.666589 [0 10.0.2.2:61581] "setnx" "limit:10:email:count" "1"
1394812740.666605 [0 10.0.2.2:61581] "setnx" "limit:10:email:reset" "1394812800"
1394812740.666621 [0 10.0.2.2:61581] "setnx" "limit:10:email:limit" "2"
1394812740.666634 [0 10.0.2.2:61581] "expire" "limit:10:email:count" "60"
1394812740.666648 [0 10.0.2.2:61581] "expire" "limit:10:email:limit" "60"
1394812740.666663 [0 10.0.2.2:61581] "expire" "limit:10:email:reset" "60"
1394812740.666679 [0 10.0.2.2:61581] "EXEC"
```

Since setnex does not exist in Redis, I used setnx + expire. The drawback is that if the key already exists, its ttl will still be changed however since it will expire in the future it may not be an real issue.

Note: A less performant option (on the network side) would be to add the expire directly inside the exec() when `res[0] === 1`.