history-db should handle OperationalError: database is locked

If you have multiple instances of loggerhead serving the same content, and sharing the same cache files, it is entirely possible that both processes will want to write to the same cache file concurrently.

This is pretty easy to trigger if you use 'bzr serve --http' and configure "http_sql_dir" so you have a permanent shared (single) cache.

A single process currently excludes multiple writers by using a threading.Lock. We should probably just spin around the OperationalError, because that allows us to support multiple concurrent processes, rather than just multiple threads in a single process.

How I set up testing this:

  http_sql_dir = /path/to/sql/cache

# Make sure the cache doesn't exist, so that serving a request takes a while to build it
rm /path/to/sql/cache/historydb.sql
cd $launchpad
bzr serve --http --port 8080 &
bzr serve --http --port 8081 &

wget http://localhost:8080/lp-branches/devel/changes &
wget http://localhost:8081/lp-branches/devel/changes &

The second request should fail and there should be a traceback about sqlite cache file locked.

Marking this critical, because it should really block landing history-db into trunk.