Investigate options for using Queue Namespaces to partition paid customer's background jobs

Originally discussed here gitlab-com/www-gitlab-com#4951 (comment 202073712) and here gitlab-com/www-gitlab-com#4951 (comment 203763223)

Areas of investigation

Option 1

2 queue namespaces: free and paid (this could be expanded to more priorities in future). Each namespace has identical queues (repository_import, post_receive etc). So, the combination would be free:repository_import, free:post_receive, paid:repository_import, paid:post_receive etc.

The application developer does not hardcode the namespace. Instead a middleware routes the job to a namespace based on the published job metadata (user, plan, etc), either to the free or paid namespace. The queue within that namespace is identical.

On the infrastructure side, we configure two clusters for sidekiq, paid will only run paid namespace jobs. free will run paid AND free. Through this approach paid jobs could run on each cluster, giving them effectively double the capacity and priority.

Option 2

Customers in their own queue namespace with dedicated Sidekiq processes for them

Other options

The above options were mentioned, but should not be considered the only options. There may be other viable options available.

This issue is blocked by the completion of gitlab-com/gl-infra&96 (closed)