Paginate shared runners in project CI/CD settings

Summary

Similar to #31159 (closed) and #267028 (closed), we should paginate the shared runners on a projects CI/CD Settings page to prevent slow loading and increase responsiveness of this page. If a GitLab instance has a large number of Runners such as 80,000, this would cause the page to timeout and cause 500s.

Steps to reproduce

  1. Add a large number of shared runners (our customer had 89,000 runners unintentionally)
  2. Attempt to load <group>/<project>/-/settings/ci_cd and observe the slow performance, or a 500 error.

Example Project

See ZD Ticket: https://gitlab.zendesk.com/agent/tickets/270124

What is the current bug behavior?

<group>/<project>/-/settings/ci_cd takes a very long time to load or returns a 500 if there is a large number of shared runners.

What is the expected correct behavior?

<group>/<project>/-/settings/ci_cd should be speedier to load and shared runners are paginated.

Relevant logs and/or screenshots

"exception.class": "Rack::Timeout::RequestTimeoutException",
    "exception.message": "Request ran for longer than 60000ms",
    "exception.backtrace": [
      "lib/gitlab/instrumentation/redis_interceptor.rb:61:in `read'",
      "lib/gitlab/instrumentation/redis_interceptor.rb:26:in `call'",
      "app/models/concerns/redis_cacheable.rb:45:in `block (2 levels) in cached_attributes'",
      "lib/gitlab/redis/wrapper.rb:23:in `block in with'",
      "lib/gitlab/redis/wrapper.rb:23:in `with'",
      "app/models/concerns/redis_cacheable.rb:44:in `block in cached_attributes'",
      "lib/gitlab/utils/strong_memoize.rb:30:in `strong_memoize'",
      "app/models/concerns/redis_cacheable.rb:43:in `cached_attributes'",
      "app/models/concerns/redis_cacheable.rb:24:in `cached_attribute'",
      "app/models/concerns/redis_cacheable.rb:17:in `block (2 levels) in cached_attr_reader'",
      "app/models/ci/runner.rb:269:in `status'",
...
"ee/app/views/projects/settings/ci_cd/show.html.haml:1",

Output of checks

This happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Similar work was done in !45830 (merged)

Edited by Anton Smith