This allows overriding of low-level locking functions.  This allows
special effects such as non-blocking operations, and lock proxying.

We rename some local lock vars to l to avoid -Wshadow warnings.

And don't double-log.  Both of these cause problems if we want to do
tdb_transaction_prepare_commit non-blocking (and have it fail so we can
try again).

This allows the caller to implement clear-if-first semantics as per
TDB1.  The flag was removed for good reasons: performance and
unreliability, but SAMBA3 still uses it widely, so this allows them to
reimplement it themselves.

(There is no way to do it without help like this from tdb2, since it has
 to be done under the open lock).

1) The logging function needs to append a \n.
2) The transaction start code should be after the comment and print.
3) We should run tdb_check to make sure the database is OK after each op.

Also, rename private logfn to log_fn for consistency with other members.

We use underscores everywhere else, so be consistent.

It's redundant calling hash.hash_fn for example.  Standardize on fn
and data as names (private conflicts with C++).

This gives us more locks for future use, plus allows a clear-if-first-style
hack to be implemented.

1) Fix the bogus reporting of uncoalesced runs: there has to be more than 1
   free record to make a "run", and any other record interrups the run.
2) Fix the bogus data count in the top line (which was number of records,
   not bytes).
3) Remove the count of free buckets: it's now a constant.

Douglas Bagnell noted that it didn't specify.

It's common when integrating CCAN into existing projects that they define
such constants for themselves.  In an ideal world, the entire project
switches to one set of definitions, but for large projects (eg SAMBA)
that's not realistic and conflicts with the aim of making CCAN modules
easy to "drop in" to existing code.

(This is a generalization of Douglas Bagnell's patch sent in Message-ID:
<4DB8D00D.8000800@paradise.net.nz>).

Makes it easier to reuse this code in other projects.

It's useful for developers, but not so much for casual users.  For example,
RHEL 5.6 has qsort_r, but no prototype, which causes a warning.

Otherwise, _GNU_SOURCE isn't defined (for example) so prototypes such as
isblank can be missing.

If the line is made solely of whitespaces, they get removed and we end up with len
set to -1. Therefore we need an additional check to avoid dereferencing line[-1].

Inspired by patch from Volker.

Get rid of many variants, which were just confusing for most people.
Keep typesafe_cb(), typesafe_cb_preargs() and typesafe_cb_postarts(),
and rework cast_if_type() into typesafe_cb_cast() so we stay in our
namespace.

I should have done this as soon as I discovered the limitation that
the types have to be defined if I want const-taking callbacks.

Don't check the whole source, but it's nice for headers to be C++-clean.

Defines whether it's useful to do #define _FILE_OFFSET_BITS 64 to get a
larger off_t.

Most Linux systems use glibc and therefore have qsort_r() and for the others an
implementation is provided, therefore there is no need to have a third case in
asort.

This avoids a warning on systems that have a 16bit wide mode_t.

Leave old hacky #ifdef tests there for reference.

tools/ccanlint/file_analysis.c needs to include config.h to set _GNU_SOURCE
before any other header file includes stdlib.h.

This is important because we tell people to use --failpath to reproduce a
failure, but the fail path we list only goes up to the last failure injection
if the child dies, for example.

Thanks to David Gibson for prodding me to fix this...

This allows for access to the end of the list, in case we need it
later (eg. moving free list entries to the end of the list after
failed coalescing?).

Turning getpagesize() into a constant 4096 really helps gcc optimize, and
not just on 64 bit.

Here are the results of running "tools/speed --transaction --no-sync 2000000":

i386 with gcc 4.4.5:
Before:
	$ ./speed --transaction --no-sync 2000000
	Adding 2000000 records:  1195 ns (93594224 bytes)
	Finding 2000000 records:  719 ns (93594224 bytes)
	Missing 2000000 records:  429 ns (93594224 bytes)
	Traversing 2000000 records:  523 ns (93594224 bytes)
	Deleting 2000000 records:  901 ns (93594224 bytes)
	Re-adding 2000000 records:  1032 ns (93594224 bytes)
	Appending 2000000 records:  1711 ns (182801232 bytes)
	Churning 2000000 records:  3233 ns (182801232 bytes)

After:
	Adding 2000000 records:  868 ns (93594224 bytes)
	Finding 2000000 records:  569 ns (93594224 bytes)
	Missing 2000000 records:  369 ns (93594224 bytes)
	Traversing 2000000 records:  406 ns (93594224 bytes)
	Deleting 2000000 records:  674 ns (93594224 bytes)
	Re-adding 2000000 records:  730 ns (93594224 bytes)
	Appending 2000000 records:  1144 ns (182801232 bytes)
	Churning 2000000 records:  2085 ns (182801232 bytes)

Here's the effect (average of 10) on x8664 with gcc 4.1.2, with an earlier
tree and 1000000:
	Before:
		Adding 830.1ns
		Finding 428.3ns
		Missing 250.3ns
		Traversing 387.4ns
		Deleting 588.8ns
		Re-adding 737.2ns
		Appending 1141.4ns
		Churning 1792ns

	After:
		Adding 562.8ns
		Finding 362.1ns
		Missing 226.4ns
		Traversing 276.5ns
		Deleting 426.7ns
		Re-adding 489.8ns
		Appending 736.4ns
		Churning 1112.7ns

We keep looking even if the current best is exactly right.  This is
really bad, because our smaller free lists hold exactly one size: with
this bug we iterate to the end of the list before hitting the end and
deciding we can use it after all.

Before:
	$ ./speed --transaction --no-sync 2000000
	Adding 2000000 records:  1179 ns (93594224 bytes)
	Finding 2000000 records:  694 ns (93594224 bytes)
	Missing 2000000 records:  429 ns (93594224 bytes)
	Traversing 2000000 records:  519 ns (93594224 bytes)
	Deleting 2000000 records:  896 ns (93594224 bytes)
	Re-adding 2000000 records:  1129 ns (93594224 bytes)
	Appending 2000000 records:  1713 ns (182801232 bytes)
	Churning 2000000 records:  32612 ns (182801232 bytes)

After:
	$ ./speed --transaction --no-sync 2000000
	Adding 2000000 records:  1195 ns (93594224 bytes)
	Finding 2000000 records:  719 ns (93594224 bytes)
	Missing 2000000 records:  429 ns (93594224 bytes)
	Traversing 2000000 records:  523 ns (93594224 bytes)
	Deleting 2000000 records:  901 ns (93594224 bytes)
	Re-adding 2000000 records:  1032 ns (93594224 bytes)
	Appending 2000000 records:  1711 ns (182801232 bytes)
	Churning 2000000 records:  3233 ns (182801232 bytes)

This helps us see where the problems are.