In the process, make the database connection object global because we
have to reconnect in order for the database settings to take effect and
thus have to reassign the variable.

The transaction_conflict test in its previous form would deadlock
because PostgreSQL locks tables/rows instead of aborting on every
conflict. The fix is to force a rollback by first reading and then
updating in both transactions, which would result in a lost update
otherwise.

Means we have to check if the user exists separately from checking the
offer.

Scanner aborts when lines are too long and is more flexible wrt.
line separators.

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.