We were getting occasional failures: if all values are the same it's a 1-line
graph and there's no "|" anywhere.

Currently they sit in each module.

Macro packages do this.

This is a precursor to doing something useful with them.

As per-tdb's tools.

We want it to complain if it's wrong...

That way we match our comment about optimal tally_new() arg matching histogram height.

Including pretty graphs!

Not as trivial as you might think, with overflow and underflow.

This flag to tdb_open/tdb_open_ex effects creation of a new database:
1) Uses the Jenkins lookup3 hash instead of the old gdbm hash if none is
   specified,
2) Places a non-zero field in header->rwlocks, so older versions of TDB will
   refuse to open it.

This means that the caller (ie Samba) can set this flag to safely
change the hash function.  Versions of TDB from this one on will either
use the correct hash or refuse to open (if a different hash is specified).
Older TDB versions will see the nonzero rwlocks field and refuse to open 
it under any conditions.

If the caller to tdb_open_ex() doesn't specify a hash, and tdb_old_hash
doesn't match, try tdb_jenkins_hash.

This makes life simpler, especially with the upcoming TDB_INCOMPATIBLE_HASH
flag.

This is a better hash than the default: shipping it with tdb makes it easy
for callers to use it as the hash by passing it to tdb_open_ex().

Also remove TDB_DISALLOW_NESTING flag, since that's the default now.

This is Stefan Metzmacher <metze@samba.org>'s patch with minor
changes:
1) Use the TDB_MAGIC constant so both hashes aren't of strings.
2) Check the hash in tdb_check (paranoia, really).
3) Additional check in the (unlikely!) case where both examples hash to 0.
4) Cosmetic changes to var names and complaint message.

We must not endian-convert the magic string, just the rest.

But make sure we can still do tdb_check() inside a transaction (weird,
but we previously allowed it).

(Imported from SAMBA commit bc1c82ea137e1bf6cb55139a666c56ebb2226b23)

Author: Jeremy Allison <jra@samba.org>
Date:   Wed Jul 28 05:15:40 2010 -0700

Fix tdb_check() to work with read-only tdb databases. The function tdb_lockall() uses F_WRLCK internally, which doesn't work on a fd opened with O_RDONLY. Use tdb_lockall_read() instead.
    
Jeremy.

Interestingly, valgrind didn't even notice.  But it crashed on (some) PowerPC.

Because we (temporarily!) marked the tdb read_only=true, any remap would
mmap PROT_READ, and the next store would SEGV.

Pulled in more test infrastructure from tdb.