Deduplicate scheduled AssignResourceFromResourceGroupWorker jobs

What does this MR do and why?

TLDR: this makes sure that scheduled AssignResourceFromResourceGroupWorker jobs (those called with perform_in instead of perform_async) still get deduplicated.

Further details

We recently introduced Re-spawn the AssignResource worker if busy (!147313 - merged) behind a Feature Flag (respawn_assign_resource_worker).

Before the respawn_assign_resource_worker was enabled, jobs in the pipelines often get stuck "waiting for resource" when there is more than one pipeline running at the same time. With the respawn_assign_resource_worker enabled, the jobs are no longer stuck with even up to 10 pipelines running at the same time.

However, looking at the logs, the re-spawned jobs don't seem to get deduplicated at all. While we don't expect re-spawned jobs to get deduplicated all the time, we still expect it to get deduplicated sometimes because it might "clash" with another AssignResourceFromResourceGroupWorker job that was, for example, queued through a state transition.

From the docs, scheduled jobs do not get automatically deduplicated. This MR makes sure that scheduled AssignResourceFromResourceGroupWorker jobs still get deduplicated.

Initial testing

The testing for the initial bug fix (Re-spawn the AssignResource worker if busy (!147313 - merged)) was done an example production group, where the pipeline structure is as follows:

• there is one project (universal-rover) that serves as the "deployment project"
• the universal-rover project triggers downstream pipelines in 10 different "application projects"
• the 10 application projects each have their own deployment pipelines, with further child pipelines

Here is what a single pipeline in this example group looks like: https://gitlab.com/dkua1_ultimate_group/private/zd/gitlab-job-stuck-at-waiting-status-460524/universal-rover/-/pipelines/1248438407

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

N/A

How to set up and validate locally

Please see: !147313 (merged)

The Sidekiq jobs can be monitored on: <your-local-gitlab-url>/admin/background_jobs

Related to #436988 (closed)