Split Snapback Sync queue into separate queues for Manual and Recurring

[SidSethi]

Description

What is the purpose of this PR? What is the current behavior? New behavior? Relevant links (e.g. Trello) and/or information pertaining to PR?

Notion doc

Problem: manual (high pri) syncs sometimes are blocked on recurring (low pri) syncs - this can happen if the queue has active tasks up to max concurrency, many of which are likely to be recurring syncs. This is suboptimal since manual syncs block user interaction and should never be blocked by background syncs.

Solution: create two queues: ManualSyncQueue and RecurringSyncQueue, each with their own max concurrency.

Tests

List the manual tests and repro instructions to verify that this PR works as anticipated. Include log analysis if possible.
❗ If this change impacts clients, make sure that you have tested the clients ❗

1. Updated CN snapback unit and integration tests to reflect updated behavior
2. Confirmed mad-dog snapback test works

❗ Reminder 💡❗:
If this PR touches a critical flow (such as Indexing, Uploads, Gateway or the Filesystem), make sure to add the requires-special-attention label. Add relevant labels as necessary.

[dmanjunath]

This looks good. Looks pretty straightforward. Had one q (possibly no-op) and mad dog is failing. once those are addressed I can re-approve

[SidSethi]

This looks good. Looks pretty straightforward. Had one q (possibly no-op) and mad dog is failing. once those are addressed I can re-approve

for mad-dog failure, it only failed on the merge commit and succeeded on each of 3 previous commits. so if anything failed it was from master - i'm re-running now tho and will see

[hareeshnagaraj]

Have some questions, no blockers

[dmanjunath]

Amazing!