parameterize option for number of concurrent workers
this is required because if the number of CRs are pretty high, we see workerQueue getting piled up and sync events may even miss an entire cycle.
for example, when running around 100 CRs concurrently, we see that wait time in queue is consistently around 30-40s
Changes proposed on the PR:
for example, when running around 100 CRs concurrently, we see that wait time in queue is consistently around 30-40s