Geo: Simplify job picking algorithm for schedulers

What does this MR do and why?

Simplifies the job picking algorithm for Geo scheduler workers. I don't expect users to notice a difference. Most data types use events to sync and trigger verification quickly, so this mainly impacts backfilling of large instances, which is expected to take a long time.

Compared to before, short queues will no longer be delayed by the presence of extremely long queues. To put it another way, queues no longer increase in priority in proportion to their length.

Related to https://gitlab.com/groups/gitlab-org/-/epics/6129#note_649158033 (The impetus for this small change is to remove code that is licensed under CC-BY-SA.)

Screenshots or screen recordings

Example Before

➜  gitlab git:(master) bin/rails c
--------------------------------------------------------------------------------
 Ruby:         ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x86_64-darwin20]
 GitLab:       14.4.0-pre (58c5a68a064) EE
 GitLab Shell: 13.21.1
 PostgreSQL:   12.6
 Geo enabled:  yes
 Geo server:   primary
--------------------------------------------------------------------------------
Loading development environment (Rails 6.1.4.1)
[2] pry(main)> queue_1 = %w{a b c}
=> ["a", "b", "c"]
[3] pry(main)> queue_2 = %w{d e f g h i j k l m n o p q r s t u v w x y}
=> ["d", "e", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y"]
[4] pry(main)> queue_3 = %w{z}
=> ["z"]
[5] pry(main)> Geo::Scheduler::SchedulerWorker.new.send(:take_batch, queue_1, queue_2, queue_3)
=> ["d", "e", "f", "g", "a", "h", "i", "j", "k", "l", "m", "n", "b", "z", "o", "p", "q", "r", "s", "t", "u", "c", "v", "w", "x", "y"]

Example After

[7] pry(main)> Geo::Scheduler::SchedulerWorker.new.send(:take_batch, queue_1, queue_2, queue_3)
=> ["a", "d", "z", "b", "e", "c", "f", "g", "h", "i", "j", "k", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "w", "x", "y"]

How to set up and validate locally

1. Be using Geo
2. Observe that syncing and verification still functions. E.g. visit /admin/geo/nodes.

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.