Try real hard to get a write lock for xapian.
Try real hard to get a write lock for xapian.

* The symptom I'm seeing is that every so often, the fedora-packages
  fedmsg-based updater will go into a failure mode where it can never
  get a write lock on the xapian database.  It just fails over and over
  again for every message.  This causes fedora-packages to ingest no new
  packages once it occurs (until one of us goes and restarts it, at
  which point it is annoyingly too late).
* Unless I missed something somewhere, there should be **no** other
  processes writing to the database, so there shouldn't be anything else
  holding that lock.
* There's this big ``try``/``finally`` block in there that is *supposed*
  to call ``indexer.indexer.close()`` at the end.  If this is the only
  place a write lock is acquired, then that leads me to think that some
  exception in either ``pull_icons`` or ``cache_icons`` is causing it to
  die early and not return the lock.

So, to deal with that stuff, this commit:

* Catches and ignores exceptions from those ``pull_icons`` and
  ``cache_icons`` calls so that we can still try to return the lock at
  the end.
* In the event that we still cannot get the lock, we'll spin and try to
  acquire it until it works.  This will prompt a human to come take a
  look so we can diagnose.  (The lock uses fnctl, and supposedly we can
  look for a ``cat`` process in the ``ps`` list holding a file called
  ``flintlock`` in ``/var/cache/fedoracommunity``).

fedora-infra/fedora-packages,fedora-infra/fedora-packages,fedora-infra/fedora-packages,fedora-infra/fedora-packages