Optimistically fixes #2223.

I say "optimistically" because we're limited by my decision to remove createdAt from Redis-stored tokens back in #2235. Because of that change, we need the proper session token object from MySQL in order to make a decision about pruning. But of course, many session tokens were already pruned from MySQL so we don't know what their createdAt was and can't prune them. Fixing that properly would require us to speculatively read from MySQL for every token in Redis, which is obviously not practical given the size of our database.

Instead, the approach I've taken here is to conditionally prune tokens from Redis whenever we encounter an expired session token object from MySQL. There are two places where that can happen: the authentication hook in lib/server.js and when returning the session token array from db.sessions. (remember that db.devices is no use because we never expire session tokens that have a device record)

This seems like the best option to me. Even if we were to reintroduce createdAt to Redis now, we'd still never be able to prune all of the older tokens. Here we get the same result but we don't pay to store the extra field in Redis.

The last commit in this changeset may be contentious, so I've left it out on it's own: d8ec9f5 . It reduces the default maximum age a token must be to qualify for pruning, from 3 months to a month. 3 months would have matched the setting we use for MySQL, but I think that's worse because there's a finite window in which we can prune tokens from Redis, which is only until they've been pruned from MySQL. Reducing maxAge increases the length of that window. And the reasons for the increased maxAge in the MySQL pruning don't apply here, I think.

If you want to test this out locally, you need to run against the MySQL back-end and use workbench to manually edit the value of createdAt for the token(s) you want to prune. Then you can use redis-commander (or whatever) to verify that the token was actually pruned.

@mozilla/fxa-devs r?