Invalid conflict resolution when choosing the Local file, if the Remote file has been renamed before

Nuxeo Drive has an incorrect way to resolve the conflict when this scenario played:

1. Set up a Drive sync'd folder containing at least one file
2. Suspend the client synchronization
3. Edit the server-side document so that its filename is changed
4. Edit the client-side file
5. Resume the synchronization
6. The conflict is detected, resolve it by choosing to keep the local file

• Expected behavior: The server document has its file replaced with the client file, with the client's filename, and otherwise retains the server file's metadata.

• Observed behavior: The server document is untouched. The client document is uploaded as a brand new File. Also, Nuxeo Drive is unaware the the server document still exists (its file is missing from the client folders).

The real issue with this behavior is that the new file has none of the property values it held before the conflict (custom schemas, etc.), making it difficult to fix things manually afterwards.

I looked a bit into the client behavior, and suggest one of the two following fixes:

1. Split the resolution in two steps: renaming the server file to the new client name, then uploading the file.
2. Replace or improve the "batch/upload" call to have something aware of the document UUID we're targeting, instead of relying on the file name.

(Note: Tested only with a Nuxeo 5.6 server)