Increase from:
	1985 of 2553 lines covered
to:
	2020 of 2552 lines covered

Increase from:
	1985 of 2553 lines covered
to:
	2018 of 2552 lines covered

Increase from:
	1962 of 2553 lines covered
to:
	1985 of 2553 lines covered

The "ret < n" was done as an unsigned comparison, so it didn't work as
expected when ret was negative.

Simplest fix is to do an equals comparison everywhere, which is also
slightly stricter.

You can always specify the TDB_NOLOCK flag along with O_RDONLY for the old
behaviour.

If benchmarking indicates a problem later, we can restore it.

Mostly a fairly simple transformation, since 0 still means success.

One new twist is that tdb_nextkey now frees the .dptr of the key; this
us usually what we want but does cause issues for our weird test code.

Of course, we leave the API the same, but percolate error codes all the
way back to tdb_check().

In particular, tdb_needs_recovery() can now indicate an error occurred,
rather than returning true.

This time we have to use our tri-value "tdb_bool_err" type to indicate
true, false, or error, which now allows us to correctly handle errors
in key matching (rather than treating it as a non-match).

In particular, we replace the TDB_OFF_ERR ((off_t)-1) with a range of
negative error values.

This causes a subtle enhancement in tdb_direct(): it previously
returned NULL on both "can't use direct access" or "some error
occurred", as the caller always uses read/write functions as a
fallback anyway.  Now we distinguish the error case.

We have a series of I/O functions which change depending on whether we're
inside a transaction or not.  This makes them return enum TDB_ERROR instead
of int.

This snuck in fe55330a which added the stats attribute.  Without it,
TDB works but is vulnerable to segmenation faults or write errors when
disk is exhausted.

Make the other functions in lock.s return an error code, too.

We make tdb_brlock() and tdb_lock_gradual() return an error code directly:
the callers have to set tdb->ecode. 

I use the "high pointers hold error numbers" trick, and also make
tdb_logerr return the error code, which enables the common case of
"return tdb_logerr(...)".

This prepares us for changing function returns over.

It's not actually different from tdb_traverse().  We can re-add it later if
it makes sense.

We do this lower down anyway.

It doesn't help the user, since they can't use it to declare their hash
function, and it just adds a level of mental indirection for us.

We don't actually support it, so take it away for the moment.  If you
try to nmest you get a TDB_LOG_USE_ERROR message.

It was never clear to me which levels should be used for what cases.
I can only usefully distinguish three at the moment:
(1) TDB errors, which render the TDB unreliable.
(2) TDB user errors, caused by API misuse.
(3) TDB notifications of strange behaviour, from which we have recovered.

Gets us one extra ccanlint point, too.

This should never happen.

Log it at level ERROR and log the raw unformatted message at the requested
level.

This is a fairly sophisticated use of failtest:
1) There are a few places where we can inject failures without revealing it
   at the API level, eg. opening /dev/urandom, or allocation failure in logging.
2) We want to be sure that (almost) all failures cause a message to be logged.
3) We need to exit as soon as possible when a failure is injected, to avoid
   combinatorial explosion.
4) We don't want to simply exit on any log message, since we want to be sure
   that cleanup happens.

This test found four different bugs failure paths.  Erk!

Since failtest uses macros to override read and write, we need to avoid
those names, even inside our ops structure.