Now we can use get_user/get_otp without having to open a transaction
each time (which also fixes a leak of transactions if an error occurs).

The Lookahead var should indicate how often the counter is incremented
before an offer is finally declared invalid, *not* the total number of
checks (aka window size).
I.e. for Lookahead=0, check only against the current counter instead of
not at all.

Because we don't want to keep the connection open while delaying for a
failed login, return the lock from handle_conn if the unlock should be
delayed. serve then closes the connection and sleeps before calling
Unlock().

- sqlite3.ErrNo is not an sqlite3.Error, we have to unpack it first
- an interrupted transaction in an in-memory database (with shared
  cache) leads to ErrLocked, while in a regular file-backed databes an
  ErrBusy is returned

For testing.

Not sure if Prepare can actuall fail because of a transaction conflict,
but checking can't hurt.

Faking ratelimiting for non-existent users would require keeping state
for every requested user, effectively allocating an unbounded amount of
memory. Enumerating users seems like the smaller problem, especially
since the targeted environment has a semi-public list of users anyway.

Server mostly works, using SQLite.