Compared with simply walking the commits with JGit, running Gerrit
commit validators is quite expensive. When pushing a large number of
commits directly to a branch, validation may exceed the timeout allowed
by AsyncReceiveCommits. For example, pushing the full Linux kernel
history of 650k commits allows only 370 microseconds of validation time
per commit, if validation is allowed to take up the full 4 minute
default AsyncReceiveCommits limit. Gerrit's validators have never been
particularly optimized, so it wouldn't be entirely surprising to see a
timeout in this case, particularly if the Gerrit server is under
moderate to heavy load.
Add a limit configured with receive.maxBatchCommits, analogous to the
existing receive.maxBatchChanges. The options are still separate:
maxBatchChanges is about creating changes, which is a far more
heavyweight operation as it needs to write change metadata, and
accidentally pushing too many changes is a bigger mess to clean up.
Change-Id: I4b81b1f99d9dafdc365ff66e0fb812877355e3b9
7854219e48