chore: log sync phases in legacy code and new code - WPB-15289

[jullianm]

WPB-15289 Report slow sync time

Issue

This PR adds logs for the duration of a sync phase as well as the full duration of a sync to complete (quick or slow sync).
Added to both legacy code and new code in WireDomain.

It will help us analyze and compare the duration between the old sync mechanism and the new one on Datadog.

Testing

N/A

Checklist

• Title contains a reference JIRA issue number like [WPB-XXX].
• Description is filled and free of optional paragraphs.

Logs would look as follows:

[github-actions]

Test Results

2 723 tests   2 721 ✅  4m 11s ⏱️
    4 suites      2 💤
    4 files        0 ❌

Results for commit 9b0d2d1.

♻️ This comment has been updated with latest results.

[datadog-wireapp]

Datadog Report

Branch report: chore/add-time-spent-logs-quick-slow-sync
Commit report: 80ddbbb
Test service: wire-ios-mono

✅ 0 Failed, 2589 Passed, 2 Skipped, 2m 45.87s Total Time

[netbe]

logic looks good, but data must be in attributes in order to use it in datadog, see comments

[netbe]

Suggested change

	let message = "Completed \(syncType) phase \(phase) in \(duration)"
	WireLogger.sync.info(message, attributes: .safePublic)
	let message = "SyncPhase completed"
	WireLogger.sync.info(message, attributes: [.duration: \(duration), .syncType: syncType, .phase: phase], .safePublic)

better to move the info inside attributes so in datadog we can extract it directly.

[jullianm]

done in aaa6638

[netbe]

Suggested change

	let message = "Completed \(syncType) in \(syncTimeTracker.totalSyncDuration())"
	WireLogger.sync.info(message, attributes: .safePublic)
	let message = "Completed \(syncType)"
	WireLogger.sync.info(message, attributes: [.sync_duration: syncTimeTracker.totalSyncDuration(), .syncType: syncType], .safePublic)

[jullianm]

done in aaa6638

[netbe]

maybe add an attribute syncSystem: "legacy" or syncSystem: "new" to distinguish which system is running. it should contain same attributes as in new system

[jullianm]

done in aaa6638

[samwyndham]

Un-assigning myself as this PR already has a couple of active reviewers. @jullianm Feel free to add me back if you would like.

[jullianm]

I've noticed a funny duration number for the first slow sync phase in legacy code. Probably the time we trigger the timer for this first event should be set later on. I suspect the time we determine the initial sync phase is not the time we actually start to perform the fetch.
I will investigate on that. @netbe

[jullianm]

So, the weird duration value for the first slow sync phase would only occur when we run into the case where we have too many devices: we determine the first slow sync phase and start the slow sync but the app is kind of in an idle state where the first phase is not being actually executed until we removed a device (issue was that the timer would've already started).

Solution is to start the timer only when the first slow sync phase is actually executed, commit b54bbc1

@netbe