The problem was if there was a false conflict: the file has been touched
both on the server and the client.
- etag has changed on the server
- mtime has changed on the server and the client and is the same
- and file size is the same on both the server and the client
This may also happen if the file is uploaded on the server, but the client
looses connection (or crashes) before it get notified of the etag.
In both tree, the instruction is EVAL, but we reduce it to a NONE because
we detected that the conflict is 'false'. Still, we need to update the db
with the new etag. (_should_update_db)
The problem was that we would set the flag on the wrong tree.
This was not a problem when the file was NEW on both side since we checked
for null etag and used the other one then.
In case two renames are done on the same file/folder very quickly we
lost the information that the second operation was also a rename. That
was because we tried to get the inode value from a stat on the file once
the first rename was finished. But at that point, the file was already
gone because of the second rename.
Now the original inode is kept and written to db in case the file can
not be stat'ed.
This fixes bug #1737
We fetch the id from the server, but don't save them in the database.
I Could have used INSTRUCTION_UPDATED for that, but then i would need to update the
reconcile algorithm to take in account the fact that UPDATED is possible there.
Instead, use should_update_etag which means the db is going to be written again
Remove reference to old instruction _UPDATED and _DELETED which does not make sens with
the new propagator
Improve the test to test this case, and that etags are properly writen to the DB
when there is a fake conflict
