Fix related changes for excessive numbers of patch sets

The first step in GetRelated is to look for all changes with a group
matching any of the groups mentioned in any of the patch sets of the
input change. The total number of groups is unbounded, and in the common
case of a 1-change series, each patch set will get its own group. This
means that the number of terms in the query grows, unbounded, with the
number of patch sets, potentially exceeding the backend-supported term
limit.

Work around this in the simplest way possible, by issuing multiple
queries and merging the results. This is a little ugly for now because
of the way that InternalQuery uses a single QueryProcessor instance, but
there are only two callers, so it's not that bad.

It is now possible for a single GetRelated call to fan out to multiple
search queries, but as this only affects changes with hundreds or
thousands of patch sets, and the fanout is only by a small factor, it
should have negligible performance impact.

Change-Id: I71b1172c0b91078d320ce56e15e1eaf218687a65

java/com/google/gerrit/acceptance/BUILD

@@ -15,6 +15,7 @@ java_library(
         "//java/com/google/gerrit/extensions/restapi/testing:restapi-test-util",
         "//java/com/google/gerrit/gpg/testing:gpg-test-util",
         "//java/com/google/gerrit/httpd",
+        "//java/com/google/gerrit/index",
         "//java/com/google/gerrit/launcher",
         "//java/com/google/gerrit/lucene",
         "//java/com/google/gerrit/metrics",