added 'created' to all tokens and 'generation' to accounts

[dannycoates]

This doesn't actually do anything with the timestamps, it just brings them into existence. The 'generation' on accounts isn't necessarily for this proposal but it could be used for that; I was specifically thinking about #388 (comment)

While I was at it I did a minor refactor to pull all of the sql statements up a notch. Also, it turns out that db_tests.js was totally busted and would silently always use heap.js. 🍌

Lots more work to do in this area, but this is mergeable, so r?

P.S. bigint for timestamps, yea or nay?

[ckarlof]

See #486 as well.

[ckarlof]

Bike shedding a bit, but generation can also be viewed as a createdAt annotation of the password verifier, correct? That makes it a bit more explicit when it should change and what it means vs generation.

[dannycoates]

I agree, generation is a nebulous term in this context. It should be considered a placeholder until we get more clarity on it's use cases.

[rfk]

👍 much clearer this way

[rfk]

LGTM, r+

bigint for timestamps, yea or nay?

Yea.

While there's almost zero change of a race here (e.g. two closely-spaced password-reset operations producing the same generation numbers) I think we can afford to store the millisecond timestamps for maximal precision. We were going to use bigint timestamps in sync2.0, which had a lot more timestamps than we do here.

Also we can refactor this internally later if we need to, e.g. truncate the high bits of the timestamp and store it in a smaller column.