pack-objects: optionally cache "counting objects" phase

When pack-objects is invoked by upload-pack, it may do a
considerable amount of CPU work in the "counting objects"
and delta compression phases.

If the repo is fully (or nearly fully) packed, the delta
compression goes quickly. However, the counting objects
phase can take minutes of CPU time, and for a clone, it will
only get longer as the repository grows.

This patch adds a new option, "--use-pack-cache", to
pack-objects which caches the result of the counting objects
phase. Subsequent fetches of the exact same object list will
use the cached data rather than traversing the complete
object list. We key the cache to the sha1 of the pending
object list used for the traversal, so a change in refs or a
request for a different set of refs will use a different
cache entry.

When the cache does not exist, we obviously fall back to the
traversal, and use the result to update the cache. Rather
than atomically rename into place, however, we actually take
a lock. This allows concurrent packs of the same data to
wait on each other, rather than thrashing the CPU as they
simultaneously attempt to compute the same value.

This produces a nice speedup when simulating 30 simultaneous
clones:

  $ time sh -c '
      for i in `seq 1 30`; do
        git pack-objects --all --stdout --use-pack-cache \
	  >/dev/null </dev/null &
      done
      wait
    '

  [before]
  real     22m12.907s
  user    169m31.344s
  sys       4m37.293s

  [after; one "winner" processes, the rest block]
  real    1m6.841s
  user    1m48.507s
  sys     0m17.701s

  [another 30, with the cache already primed]
  real    0m9.182s
  user    0m55.915s
  sys     0m15.025s

The resulting cache files are a bit larger than a pack index
file (6.4M for git.git, ~100M for linux-2.6.git). The big
problem with this scheme is management of the cache files.
Clone caches are generally useful, but should go away when
refs are updated. Fetch caches are typically not all that
useful, unless you have some big repeated fetches (like
deploying from git into a cluster). But we don't know ahead
of time which fetches will be repeated.

So you'd probably want to write the cache every time, and
then aggressively prune entries that are more than a few
minutes. Or something like that. But the point is this is
not a turn-key solution, and there's a high cost to pay in
cache creation and maintenance.