Ensure check_interval takes effect and eliminate race condition between fleet of runners

Why was this MR needed?
Previously, when a worker picked up a job from GitLab, the runner would immediately send more workers to request additional jobs without waiting, causing a race condition and preventing the configured check_interval from being respected.

To address this, a new configuration option FastCheckInterval was introduced. This option is automatically enabled (true) by default, ensuring that existing runners maintain the previous fast behavior and preventing breaking changes. With this MR, users can now opt out of the fast interval by explicitly setting FastCheckInterval = false if they want strict enforcement of check_interval.

What does this MR do?

This MR changes the logic in commands/multi.go so that the call to mr.requeueRunner(runner, runners) is now conditional on FastCheckInterval.

• If FastCheckInterval = true → the previous behavior is preserved (immediate requeue).
• If FastCheckInterval = false → runners wait for the configured check_interval, avoiding race conditions.

This allows check intervals to be respected without immediately dispatching additional workers, while preserving backward-compatible behavior by default.

How to test this MR:
Deploy the updated code, run multiple runners concurrently, and execute a pipeline with multiple jobs. With FastCheckInterval enabled (default), the previous fast behavior is preserved and jobs will be have less queue times.

When disabled, each runner will wait for the configured check_interval before picking up a new job. This prevents race conditions and ensures predictable job distribution.

Related Issues:

gitlab#15963, #3678 (closed)