Long running synchronization initiation blocks subsequent scheduled syncs and other scheduled tasks

When a synchronization takes a long time to run in RepositoryServiceImpl.syncRepositoryList, it occupies the SYNC_REPOSITORY_LIST_LOCK for synching repositories (for all organizations). This would block subsequent syncs that need to enter the same code block, even for syncs for other organizations.

One example of the long running-ness is due to a long running SELECT query in DCON-425.

This issue could cause all (the four) clustered scheduler threads to be used up by the DVCS Connector, thus no other clustered scheduled tasks could be run.

There are a few things to improve here:

1. The sync should be moved outside of the scheduler thread
   • The scheduler thread should be just kicking off the sync and immediately return to free up the thread for other scheduler jobs.
2. The SYNC_REPOSITORY_LIST_LOCK is too exclusive.
   • It could be applied to per organization, instead of to the whole DB
3. The attempt to lock should timeout, once we change the lock to be per org
   • When the lock is occupied, it means that previous sync is still running.
   • We need to be careful when we extend the sync period dynamically.