fix(DataStore): Reconcile mutation responses from conflict handler path

[lawmicha]

Issue #

Description

This PR passes the reconciliationQueue to the ProcessMutationErrorFromCloudOperation to reconcile conflict-handler resulting mutation responses. Reconciliation will update the local model's metadata version to keep it up to date.

The impact; normally this is not needed since the subscription events should funnel into the reconciliation queue, however this is not the case for apps that have disabled subscriptions. There are some clients that disable subscriptions for various reasons, to have a limited functioning DataStore without real-time updates. For these apps, DataStore will continue to reoncile responses from locally sourced mutations so that that data local to the app will be kept up to date with the remote store as much as possible.

General Checklist

• Added new tests to cover change, if needed
• Build succeeds with all target using Swift Package Manager
• All unit tests pass
• All integration tests pass
• Security oriented best practices and standards are followed (e.g. using input sanitization, principle of least privilege, etc)
• Documentation update for the change if required
• PR title conforms to conventional commit style
• New or updated tests include Given When Then inline code documentation and are named accordingly testThing_condition_expectation()
• If breaking change, documentation/changelog update with migration instructions

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[harsh62]

Just making sure this is expected behaviour.. Even if there is an underlying error, it will still finish with a success?

[lawmicha]

Yes success and failure here is fairly loose contract between the OutgoingMutationQueue and this operation. I believe even if it's marked as a failure, OutgoingMutationQueue will continue to move on to the next mutation event in the queue (by deleting the mutation event and picking up the next). The important logic in this operation before it finishes is that it's handling the errors. When DataStore can no longer take action on the error, it will call the errorHandler (see line 315 and 320) to inform the client that the error has occurred, before we remove the mutation event.