Data Duplication

[jleandroperez]

Background
This is easily triggered with a single device, in OSX (iOS is affected as well).

Session 1

1. Pending ACK for Change 1: 'First'.
2. Pending Processing Change 2 (same object as above): 'Second'.

3. Kill the app.
   

Session 2

1. As soon as the lib reconnects, Change 1 gets re-posted.
2. Change 1 is received, in response to '0:cv:xxx' message, and processed.
3. Change 2 is processed, and posted.
4. Error 409 is received, in response to the duplicate change in step 1. That causes the local change pending to get nuked.

Bug:
When the ACK for Change 2 is received (Step 3), there is no local pending, because of the way Error 409 is being handled.
This causes the change to be treated as a new diff, instead of an acknowledgements, leading to data corruption.

Logs Available Here

[jleandroperez]

As a side effect of this pull request, this issue got fixed.

Why?:
Session 2, step 1, isn't the case anymore. The lib will now retrieve the latest changes first, and then post any local pendings. This will cause, in turn, not to trigger any 409's during the startup sequence.

For the record, the expected startup flows are:

1.  [Recv]  1:auth:jorge@lantean.co
2.  [Send]  1:cv:53443dc0ba5fdc113d341acc
3.  [Recv]  1:cv:[] <- empty changes, we are in sync
4.  [Send]  Pendings
5.  normal

1.  [Recv]  1:auth:jorge@lantean.co
2.  [Send]  1:cv:53443dc0ba5fdc113d341acc
3.  [Recv]  1:cv:[ { }, { }, { } ] <- some changes, process them, may get rid of some changes in pending
4.  [Send]  Pendings that remain
5.  normal

1.  [Recv]  1:auth:jorge@lantean.co
2.  [Send]  1:cv:53443dc0ba5fdc113d341acc
3.  [Recv]  1:cv: ?
4.  [Send]  Pendings
5.  [Send]  1:i::::500
6.  [Recv]  1:i:{"current": "53443de1ba5fdc113d342491"}
7.  [Send]  1:e:.... (Download entities)
8.  normal