Add limit to number of commits that ReceiveCommits will validate

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

Documentation/config-gerrit.txt

@@ -3541,6 +3541,15 @@ number of changes for review by mistake.
 +
 Default is zero, no limit.
 
+[[receive.maxBatchCommits]]receive.maxBatchCommits::
++
+The maximum number of commits that Gerrit allows to be pushed in a batch
+directly to a branch when link:user-upload.html#bypass_review[bypassing review].
+This limit can be bypassed if a user link:user-upload.html#skip_validation[skips
+validation].
++
+Default is 10000.
+
 [[receive.maxObjectSizeLimit]]receive.maxObjectSizeLimit::
 +
 Maximum allowed Git object size that 'receive-pack' will accept.