Gitaly N+1 queries in /api/:version/groups/:id

As seen in #mech_symp_alerts (https://log.gitlab.net/goto/0ed2e7715e9456c3bafbe9f63b5d5559), there are some queries that are reguarly taking over 500 Gitaly calls.

I can reproduce this by stubbing out RequestStore::Middleware, and then calling:

user = User.find_by(username: 'stanhu')
RequestStore.begin!
RequestStore[:peek_enabled] = true
Gitlab::Profiler.with_user(user) { app.get '/api/v4/groups/issue%2Dreproduce' }   
[ gprd ] production> Gitlab::SafeRequestStore['gitaly_call_details'].count
=> 557
[ gprd ] production> Gitlab::SafeRequestStore['gitaly_call_details'].each_with_object(Hash.new(0)) { |e, h| h[e[:feature]] += 1 }
=> {"ref_service#find_default_branch_name"=>557}

Proposal

It looks like the issue is that the list of groups is paginated, but the list of projects within the group is NOT. I think we need to consider splitting the projects of a group into a separate endpoint that can be paginated (e.g. /api/:version/groups/:id/projects).

There is already a separate endpoint to get all of a group's projects (https://docs.gitlab.com/ee/api/groups.html#list-a-groups-projects) so restricting this endpoint to return a maximum of 100 projects seems a sensible first step to mitigate the problem (and prevent abuse).