PoC - Priority Queuing for Shared Runners

What does this MR do and why?

This MR is a POC demonstrating a potential solution to a problem.

The problem

We had customers not adopt gitlab because the fair scheduling algorithm deprioritized projects with many builds.

Solution Demonstrated

One idea is to have priority queues for paid tiers. Regardless of how we design the fair scheduling algorithm we from the priority queue X% of the time and the other queue Y% of the time.

A single priority queue could look like:

# In this example we pick from the priority queue 70% of the time and the other queue 30% of the time.

module Ci
  module Queue
    class PendingBuildsStrategy
      ...
      # use an ops flag?
      PICK_FROM_PRIORITY_QUEUE_PERCENTAGE = 70

      def builds_for_shared_runner()
        case rand(100) + 1
          when  1..PICK_FROM_PRIORITY_QUEUE_PERCENTAGE then priority_shared_runner_builds
          when   PICK_FROM_PRIORITY_QUEUE_PERCENTAGE..100 then non_priority_shared_runner_builds
        end
      end
      ...
    end
  end
end

This could work with some data de-normalized onto the pending builds table with information about whether the plan demands a priority queue, so that we can avoid joining.

The implementation of priority_shared_runner_builds and non_priority_shared_runner_builds would filter based on the the de-normalized data.

Priority Queues per plan

We could also have each tier have a different priority. A speculative example:

plan	pick percentage
free	20
premium	35
ultimate	45

These could be adjusted based on need via an ops feature flag.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #354343