There's no real reason to start with 128 entries.

This lets us compare hash table vs. strset vs. the example
implementation of critbit trees.

cbspeed 100 runs, min-max(avg):
#01: Initial insert:   236-245(237)
#02: Initial lookup (match):   180-186(180)
#03: Initial lookup (miss):   171-185(172)
#04: Initial lookup (random):   441-457(444)
#05: Initial delete all:   127-132(128)
#06: Initial re-inserting:   219-225(220)
#07: Deleting first half:   101-104(102)
#08: Adding (a different) half:   158-162(159)
#09: Lookup after half-change (match):   202-207(203)
#10: Lookup after half-change (miss):   217-222(218)
#11: Churn 1:   297-302(299)
#12: Churn 2:   297-305(300)
#13: Churn 3:   301-308(303)
#14: Post-Churn lookup (match):   189-195(190)
#15: Post-Churn lookup (miss):   189-193(190)
#16: Post-Churn lookup (random):   499-513(503)

speed 100 runs, min-max(avg):
#01: Initial insert:   211-218(212)
#02: Initial lookup (match):   161-166(162)
#03: Initial lookup (miss):   157-162(158)
#04: Initial lookup (random):   452-460(454)
#05: Initial delete all:   126-135(127)
#06: Initial re-inserting:   193-201(194)
#07: Deleting first half:   99-107(99)
#08: Adding (a different) half:   143-190(144)
#09: Lookup after half-change (match):   183-195(184)
#10: Lookup after half-change (miss):   197-203(198)
#11: Churn 1:   271-278(274)
#12: Churn 2:   280-287(282)
#13: Churn 3:   277-285(279)
#14: Post-Churn lookup (match):   171-175(171)
#15: Post-Churn lookup (miss):   174-178(175)
#16: Post-Churn lookup (random):   525-552(528)

stringspeed 100 runs, min-max(avg):
#01: Initial insert:   300-343(308)
#02: Initial lookup (match):   98-136(99)
#03: Initial lookup (miss):   73-102(75)
#04: Initial lookup (random):   230-282(233)
#05: Initial delete all:   66-102(69)
#06: Initial re-inserting:   62-99(64)
#07: Deleting first half:   43-52(43)
#08: Adding (a different) half:   101-156(106)
#09: Lookup after half-change (match):   114-156(120)
#10: Lookup after half-change (miss):   94-103(95)
#11: Churn 1:   98-105(99)
#12: Churn 2:   96-104(98)
#13: Churn 3:   174-184(176)
#14: Post-Churn lookup (match):   93-112(94)
#15: Post-Churn lookup (miss):   77-107(79)
#16: Post-Churn lookup (random):   229-265(232)

Not as fast as using htable, but simple and provides order and prefix
ops.

Firstly, -Wwrite-strings makes string literals const, secondly, we mustn't
define str_strstr etc in terms of themselves!

LGPL is overkill for trivial wrappers like this.

Note where previous analysis said the code was outside a function, and
fix double new-line.  Also, treat end of comment as end of statement.

This handles both pointer and integer types using ccan/tcon.

It's now a completely generic set implementation, and uses ccan/tcon
to always be typesafe.  It handles both integer and pointer types.

No real change for users.

Previously, it was always "", since we left the nul terminator at the
start.

This happens in SAMBA with the TDB_VERSION1, presumably due to a
read-only traverse nested inside a normal traverse (since it doesn't
occur without TDB_VERSION1).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

This clarifies the code a little, but also provides a more explicit
mechanism which can be used to debug error handling (by introducing
tdb_err_t and making it a pointer type).

Measuring ccanlint -d ccan/tdb2 on my dual core hyperthread laptop gives:
Before: 5:30
After: 3:31

Lazy cut & paste of tdb names causes failure when we run in parallel.

Measuring ccanlint -d ccan/tdb2 on my dual core hyperthread laptop gives:
Before: 5:59
After: 5:30

Measuring ccanlint -d ccan/tdb2 on my dual core hyperthread laptop gives:
Before: 6:47
After: 5:59

We use the lbalance module to figure out how many to run in parallel.

Reallocing smaller can move the pointer; certainly valgrind detects
it.  Found while chasing intermittant errors on "make fastcheck".

Meets all of the requirements of ccanlint.
Code coverage of the tests covers everything except for a malloc() failure.
Added some xml files for the tests to work on.

Removed the last references of the old buffering method. Should be
stable now. Time to write some proper testing.

tdb_repack() returns an enum TDB_ERROR, whereas
tdb1_transaction_commit is expected to return 0 or -1.

A left-over -1 return; should be returning ecode (probably TDB_ERR_IO).

Since enums and ints are compatible in C, the compiler didn't warn
that our prototypes for these functions disagreed with the
definitions.

These two tdb1-specific tests have been superceded by the TDB_VERSION1
flags used in the main tests.

Don't run tdb_check with failtest on, since it is very slow.  Do the
tdb_check w/ failtest in a new test, but skip MMAP suppression which
doesn't add much and slows down valgrind a lot.

Before this change run-01-new_database took 40 seconds (under
valgrind), after it takes 8 seconds, and run-12-check takes 3
seconds).

The time to run tests under valgrind has become excessive; particularly
the failure tests which fork().   Thus we cut down testing:

1) api-94-repack: reduce from 234 seconds to 2 seconds by cutting
   iterations, despite adding TDB_VERSION1 tests.

2) api-missing-entries: reduce from 17 seconds to under 1 second by
   not checking db inside loop, but at end.

This reduces the total ccanlint time from 729 to 489 seconds.

This reduces compilation time, since these are merely linked with the
pre-built module, rather than recompiling it into the test (which
allows for fancy things like failtest).

This reduces the test compile time down from about 62 seconds to 45
seconds.  Since ccanlint compiles tests three times (once normally,
once with coverage, and once with reduced config.h) this makes a
difference: we go from 780 seconds to 729 seconds.

We track malloc and free, but we didn't catch the free() inside
external_agent, which means that our list of allocations keeps
growing.  Particularly under valgrind, which re-uses memory less than
the glibc allocator.

The TDB1 code's tdb1_find() returns 0 on error; the callers should
not assume that the error means that the entry wasn't found, but use
last_error to determine it.

This was found by looking at how long the failure path testing for
test/run-10-simple-store.c was taking under valgrind, ie:

	valgrind -q ./run-10-simple-store --show-slowest

This change dropped the time for that test from 53 seconds to 19
seconds.