Add rate limiting category to Application Performance group

GitLab provides a built-in rate limiting service to prevent noisy neighbor problems as well as other potential types of intentional and unintentional abuse. This is an important framework to ensure stable operations of GitLab services for all of our customers.

While each product group is responsible for ensuring their API endpoints and other features have rate limits adding, we need one group who can take ownership of the general rate limiting framework and ensure it has the features we need, and to provide maintenance.

Since this is a low-level ruby/rails framework, which helps to ensure even performance across the application, the Application Performance group seems like the best group to mature this framework.

Approvals

Merge requests with changes to stages and groups and significant changes to categories need to be created, approved, and/or merged by each of the below:

• VP of Product @david
• The Product Director relevant to the affected Section(s) - @joshlambert
• The Engineering Director relevant to the affected Section(s) @cdu1
• Director of Product Design @vkarnes

The following people need to be on the merge request so they stay informed:

• Chief Technology Officer @akramer
• Vice President of Development @clefelhocz1
• Vice President of Quality @meks
• Vice President of User Experience @clenneville
• The Product Marketing Manager relevant to the stage group(s) @supadhyaya
• Director of Technical Writing @susantacker

After Approvals and Merge

• Create an issue in the triage-ops project to update GitLab Bot automation:
  • for Category change
  • for Stage or Group change
• Mention the product group Technical Writer to update the documentation metadata
• Share MR in #product, #development, and relevant #s_, #g_, and #f_ slack channels