Spending order won't necessarily survive a "vacuum" operation

[exarkun]

According to https://www.sqlite.org/rowidtable.html:

If the rowid is not aliased by INTEGER PRIMARY KEY then it is not persistent and might change. In particular the VACUUM command will change rowids for tables that do not declare an INTEGER PRIMARY KEY. Therefore, applications should not normally access the rowid directly, but instead use an INTEGER PRIMARY KEY.

The unblinded-tokens table has the schema:

CREATE TABLE [unblinded-tokens] (
        [token] text, -- The base64 encoded unblinded token.
        PRIMARY KEY([token])
)

Then tokens are spent in an order defined by:

SELECT [token]
FROM [unblinded-tokens]

Additionally, tokens are discarded by the checkpoint restore mechanism like this:

DELETE FROM [unblinded-tokens]
WHERE [rowid] < ?

If the unblinded-tokens table has its rows renumbered between the time when backup is made and the checkpoint restore mechanism is used then the order of unblinded-tokens will not allow a correct checkpoint restore based on this rowid value.

As https://www.sqlite.org/rowidtable.html suggests, "instead use an INTEGER PRIMARY KEY."

[exarkun]

Conveniently, we never vacuum the database so I don't think this can hurt us yet.