sync-manager no longer queues syncs.

[mhammond]

There's no need or use-case for syncs queuing up. Any "immediate" requests are time-sensitive, and the chance of a conflict is small.

Shouldn't break consumers. Towards what @segunfamisa and I have been chatting about. cc @jonalmeida, and @bendk and @gruberb re the async discussions (sync-manager has never had a coroutine wrapper iiuc, so has always been blocking for android (ie, not actually "async", which is unusual and was a TIL 😅). Maybe relevant to the async modeling?)

See also https://bugzilla.mozilla.org/show_bug.cgi?id=2061666

Pull Request checklist

• Breaking changes: This PR follows our breaking change policy
  • This PR follows the breaking change policy:
    • This PR has no breaking API changes, or
    • There are corresponding PRs for our consumer applications that resolve the breaking changes and have been approved
• Quality: This PR builds and tests run cleanly
  • Note:
    • For changes that need extra cross-platform testing, consider adding [ci full] to the PR title.
    • If this pull request includes a breaking change, consider cutting a new release after merging.
• Tests: This PR includes thorough tests or an explanation of why it does not
• Changelog: This PR includes a changelog entry in CHANGELOG.md or an explanation of why it does not need one
  • Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
• Dependencies: This PR follows our dependency management guidelines
  • Any new dependencies are accompanied by a summary of the due diligence applied in selecting them.

[bendk]

I could see there being a use-case for something like queuing up a sync: I make a change to some engine and want to make sure other clients see it ASAP. In that case, if there's a sync going, I still might want to queue another one since that the sync for my engine might have already happened.

However, that's not needed right now and I don't think SyncManager::sync() is the method we would want to use for that anyways, so this change seems great to me.

[mhammond]

I still might want to queue another one

yeah, but this does kinda sound app specific, so having that in the Kotlin WorkManager makes some sense - eg, things like cancellation etc and other platform specific considerations are possible.

Ideal would be to allow multiple syncs to run concurrently, locking each engine, not the entire sync? That's likely somewhat possible, but not at all trivial.