Investigate redis_queues_metadata calls while resuming concurrency limit jobs for workers with until_executed deduplication strategy

From !208142 (comment 2836793433)

In !208142 (merged), we tried to optimize ConcurrencyLimit::ResumeWorker by skipping duplicate jobs check when ResumeWorker tries to resume deferred jobs.

The skipping of duplicate jobs check works as expected for until_executing (default) deduplication strategy workers as in gitlab-com/gl-infra/production#20567 (comment 2838245297).

However we noticed for until_executed workers, there are still calls to redis_queues_metadata !208142 (comment 2836793433) presumingly also from duplicate jobs check. The ratio of number of jobs : number of redis calls is 1 to 1, so it must be something that the middleware calls for each job.

From the codebase, though, UntilExecuted and UntilExecuting has no difference in the client middleware codepath (ie #schedule method), so UntilExecuted should also skip the duplicate jobs check.

Another example for FlushCounterIncrementsWorker:

src

We should figure out where those redis_queues_metadata calls are coming from for those until_executed workers.