Alternative approach to tracking free blocks in btrees

[olly]

Use chains of free blocks rather than a bitmap - then we can store many old revisions more cheaply (just the space they actually need, not a whole bitmap for each one too). Then readers use fcntl locking on a single byte corresponding to the revision they're using (bytes off the end of the file can be locked, and shared locks on read-only files are ok). Then a writer would only delete old revisions for which it could obtain an exclusive lock (otherwise it would preserve them).

The Btree manager is generally written with multiple old revisions in mind, so this shouldn't be a huge project.

[olly]

Reassigned to the flint backend.

The fcntl locking issue is now addressed (in flint).

I've also worked out how to update freelists atomically and cheaply.

[olly]

Debug tracing tweaks to help investigate this

[olly]

(From update of attachment 56) Gah! Attachment meant for a different bug. I hate bugzilla.

[olly]

Remarking for chert...