Allow Gitaly N+1s in MR finder spec

These can be triggered by project creation in the setup phase if a spec uses the
RequestStore, but we really don't care about that - it's not an N+1, it's just
several projects being created!

spec/finders/merge_requests_finder_spec.rb

@@ -3,21 +3,37 @@ require 'spec_helper'
 describe MergeRequestsFinder do
   include ProjectForksHelper
 
+  # We need to explicitly permit Gitaly N+1s because of the specs that use
+  # :request_store. Gitaly N+1 detection is only enabled when :request_store is,
+  # but we don't care about potential N+1s when we're just creating several
+  # projects in the setup phase.
+  def create_project_without_n_plus_1(*args)
+    Gitlab::GitalyClient.allow_n_plus_1_calls do
+      create(:project, :public, *args)
+    end
+  end
+
   let(:user)  { create :user }
   let(:user2) { create :user }
 
   let(:group) { create(:group) }
   let(:subgroup) { create(:group, parent: group) }
-  let(:project1) { create(:project, :public, group: group) }
-  let(:project2) { fork_project(project1, user) }
+  let(:project1) { create_project_without_n_plus_1(group: group) }
+  let(:project2) do
+    Gitlab::GitalyClient.allow_n_plus_1_calls do
+      fork_project(project1, user)
+    end
+  end
   let(:project3) do
+    Gitlab::GitalyClient.allow_n_plus_1_calls do
       p = fork_project(project1, user)
       p.update!(archived: true)
       p
     end
-  let(:project4) { create(:project, :public, group: subgroup) }
-  let(:project5) { create(:project, :public, group: subgroup) }
-  let(:project6) { create(:project, :public, group: subgroup) }
+  end
+  let(:project4) { create_project_without_n_plus_1(group: subgroup) }
+  let(:project5) { create_project_without_n_plus_1(group: subgroup) }
+  let(:project6) { create_project_without_n_plus_1(group: subgroup) }
 
   let!(:merge_request1) { create(:merge_request, :simple, author: user, source_project: project2, target_project: project1) }
   let!(:merge_request2) { create(:merge_request, :conflict, author: user, source_project: project2, target_project: project1, state: 'closed') }