Starting to many add MU at the same try create issues

[maximenoel8]

Context

Recent improvements to the reposync method have exposed a pre-existing issue where custom channels were not being correctly synced. This bug was previously hidden because the old method always reported success, masking failures silently.

The root cause is that multiple custom repository syncs are launched in parallel, but the underlying download process is sequential. When too many syncs are queued simultaneously, they hit the 10-minute timeout and fail. The consequence is that packages from custom channels may be missing when bootstrapped, leading to unreliable tests.

What does this PR do?

Introduces a throttling mechanism to limit the number of concurrent custom repository syncs to 5 at a time.

Approaches considered:

• java.util.concurrent.Semaphore — the cleanest solution, but rejected by Jenkins script security sandbox:

    org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: 
    Scripts not permitted to use new java.util.concurrent.Semaphore int

• Lockable Resources plugin (lock(resource: ..., quantity: 5)) — would be ideal, but requires admin rights to pre-configure the resource pool in Jenkins.

• synchronized counter with waitUntil — the chosen approach. A shared counter protected by a synchronized block ensures at most 5 syncs run concurrently. A try/finally guarantees the counter is always decremented even on failure, preventing deadlocks. The throttling logic is extracted into a reusable withThrottle {} closure to keep the stage code clean.

Impact

• Prevents timeout failures caused by too many parallel syncs
• Ensures custom channel packages are reliably available at bootstrap time
• No admin rights or Jenkins plugin configuration required