api: items/sync: we don't produce uuid_conflict

`uuid_conflict` only exists because the official implementation uses
`uuid` as the primary key for their database, while in ours we use an
internal ID and then use (uuid, user) tuple to fetch items. i.e. in our
implementation, user A and B can have items that have the same UUID.

src/api.rs

@@ -273,21 +273,17 @@ fn items_sync(
         });
 
     // Convert conflicts into the format our client wants
-    resp.conflicts = items_conflicted.into_iter().map(|(client_item, server_item)| {
+    resp.conflicts = items_conflicted.into_iter().map(|(_client_item, server_item)| {
-        // We assume enc_item_key "identifies" an "item"
+        // Our implementation never produces `uuid_conflict`
-        if client_item.enc_item_key == server_item.enc_item_key {
+        // because the primary key of the `items` table is an internal ID
-            SyncConflict {
+        // and we retrieve content based on (user, uuid) tuple, not just uuid.
-                conf_type: "sync_conflict".to_string(),
+        // The whole point of having `uuid_conflict` in their official impl
-                server_item: Some(server_item),
+        // is because they use `uuid` as the primary key, so two items
-                unsaved_item: None
+        // on the same server cannot share the same uuid
-            }
+        SyncConflict {
-        } else {
+            conf_type: "sync_conflict".to_string(),
-            // A UUID conflict (unlikely)
+            server_item: Some(server_item),
-            SyncConflict {
+            unsaved_item: None
-                conf_type: "uuid_conflict".to_string(),
-                server_item: None,
-                unsaved_item: Some(client_item)
-            }
         }
     }).collect();