TooManyTagsError when the number of runner tags is over 50

Summary

Recently this Issue recently limited the number of tags that can be assigned to a runner on .com. The limit is <= 50. This is affecting also affecting Self-Managed Instances and was raised through this ZDticket

Steps to reproduce

Spin up a runner v14.9.2 and above and register it with more than 50 tags.

What is the current bug behavior?

Jobs remain pending and you get an error "TaggableQueries::TooManyTagsError"

What is the expected correct behavior?

Runners with over 50 tags should accept jobs.

Relevant logs and/or screenshots

 "exception.class": "TaggableQueries::TooManyTagsError",
    "exception.message": "TaggableQueries::TooManyTagsError",
    "exception.backtrace": [
        "app/models/concerns/taggable_queries.rb:44:in `block in tags_ids'",
        "app/models/concerns/taggable_queries.rb:43:in `tap'",
        "app/models/concerns/taggable_queries.rb:43:in `tags_ids'",
        "app/services/ci/queue/pending_builds_strategy.rb:27:in `builds_matching_tag_ids'",
        "app/services/ci/queue/build_queue_service.rb:64:in `builds_matching_tag_ids'",
        "app/services/ci/register_job_service.rb:124:in `each_build'",
        "app/services/ci/register_job_service.rb:55:in `process_queue'",
        "app/services/ci/register_job_service.rb:31:in `block in execute'",
        "lib/gitlab/ci/queue/metrics.rb:97:in `observe_queue_time'",
        "app/services/ci/register_job_service.rb:30:in `execute'",
        "lib/api/ci/runner.rb:151:in `block (2 levels) in <class:Runner>'",
        "lib/api/api_guard.rb:213:in `call'",
        "lib/gitlab/middleware/memory_report.rb:13:in `call'",
        "lib/gitlab/middleware/speedscope.rb:13:in `call'",
        "lib/gitlab/request_profiler/middleware.rb:17:in `call'",
        "lib/gitlab/database/load_balancing/rack_middleware.rb:23:in `call'",
        "lib/gitlab/jira/middleware.rb:19:in `call'",
        "lib/gitlab/middleware/go.rb:20:in `call'",
        "lib/gitlab/etag_caching/middleware.rb:21:in `call'",
        "lib/gitlab/middleware/query_analyzer.rb:11:in `block in call'",
        "lib/gitlab/database/query_analyzer.rb:46:in `within'",
        "lib/gitlab/middleware/query_analyzer.rb:11:in `call'",
        "lib/gitlab/middleware/multipart.rb:173:in `call'",
        "lib/gitlab/middleware/read_only/controller.rb:50:in `call'",
        "lib/gitlab/middleware/read_only.rb:18:in `call'",
        "lib/gitlab/middleware/same_site_cookies.rb:27:in `call'",
        "lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call'",
        "lib/gitlab/middleware/basic_health_check.rb:25:in `call'",
        "lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'",
        "lib/gitlab/middleware/request_context.rb:21:in `call'",
        "lib/gitlab/middleware/webhook_recursion_detection.rb:15:in `call'",
        "config/initializers/fix_local_cache_middleware.rb:11:in `call'",
        "lib/gitlab/middleware/compressed_json.rb:26:in `call'",
        "lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call'",
        "lib/gitlab/middleware/sidekiq_web_static.rb:20:in `call'",
        "lib/gitlab/metrics/requests_rack_middleware.rb:77:in `call'",
        "lib/gitlab/middleware/release_env.rb:13:in `call'"
    ],

Possible fixes

We could either make the limit apply only on .com, or perhaps make it be a per-plan so that it is easily configurable.