Add Concurrency Limit Cop for Sidekiq workers

Description of the proposal

This MR introduces a new cop to encourage team members to set a concurrency_limit for their Sidekiq workers. This is part of an ongoing effort to reduce the number of incidents caused by Sidekiq workers overloading the system.

class LimitedWorker
  include ApplicationWorker

  concurrency_limit -> { 100 }

  # ...
end

Here's a quick example of the cop in action:

$ rubocop ee/app/workers/geo/event_worker.rb
Inspecting 1 file
C

Offenses:

ee/app/workers/geo/event_worker.rb:4:3: C: Scalability/ConcurrencyLimit: Workers should set concurrency_limit to prevent incidents. Please refer to https://docs.gitlab.com/ee/development/sidekiq/#concurrency-limit
  class EventWorker ...
  ^^^^^^^^^^^^^^^^^

1 file inspected, 1 offense detected

Check-list

• Make sure this MR enables a static analysis check rule for new usage but ignores current offenses.
• Mention this proposal in the relevant Slack channels (e.g. #development, #backend, #frontend).
• [-] If there is a choice to make between two potential styles, set up an emoji vote in the MR:
  • CHOICE_A: 🅰
  • CHOICE_B: 🅱
  • Vote for both choices, so they are visible to others.
• The MR doesn't have significant objections, and is getting a majority of 👍 vs 👎 (remember that we don't need to reach a consensus).
• [-] (If applicable) One style is getting a majority of vote (compared to the other choice).
• [-] (If applicable) Update the MR with the chosen style.
• Create a follow-up issue to fix the current offenses as a separate iteration: #499853 (closed)
• Follow the review process as usual.
• Once approved and merged by a maintainer, mention it again:
  • In the relevant Slack channels (e.g. #development, #backend, #frontend).
  • (Optional depending on the impact of the change) In the Engineering Week in Review.

/cc @gitlab-org/maintainers/rails-backend

#499837 (closed)