receive-pack: never unpack git-receive-pack packs

receive-pack: never unpack git-receive-pack packs

Git has a race condition where a simultaneous garbage collection
(even one triggered by "git gc --auto") and push (i.e. git-receive-pack)
can result in a loose object that is just becoming referenced being
deleted even though it's actually now referenced or about to be referenced.

Because the .pack mechanism supports .keep files, this same problem
cannot occur if incoming pushes always store the new objects as packs
and never unpack them.  (There is no .keep mechanism for loose objects.)

To this end, force receive.unpackLimit to be set to 1 whenever an
incoming push (i.e. git-receive-pack) occurs.  We do this in such a
way that it will override any config file settings because it's crucial
that it not be bypassed.

Unfortunately the Git documenation is wrong in that it claims that
transfer.unpackLimit is a fallback when receive.unpackLimit (or
fetch.unpackLimit) is unset.  In fact, the code behaves in the exact
opposite fashion. If transfer.unpackLimit is set the other two are
completely ignored.

Therefore we also always force transfer.unpackLimit to be set to 1
as well whenever we are forcing receive.unpackLimit to be set to 1.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>