Added rename event to watch that keeps revision history for renamed files

[miketalley]

Description and Context

When renaming/moving files currently being watched, there is a deleteRemoteFile and subsequent uploadFile that is performed, which causes the revision history to be lost for the file.

This PR looks to modify the watch command to use a new endpoint that will retain the revision history when a file/folder is renamed.

TODO

Add a bunch of unit tests.

Who to Notify

@williamspiro

[miketalley]

Unfortunately, there is no rename event provided by chokidar, which is used to provide the file watching functionality. (see Add a "rename" event issue #303).

I added custom code and got revision history to be retained for moving individual/multiple files, but in this case folder moves were not working properly. After adding code to handle identification of moved folders(through raw moved events) to prevent deletion of files within them, the folder moves w/ content were working, however normal file deletion functionality was compromised(the file was being identified as moved due to the raw moved event being triggered).

I'm not sure a solution is possible that will allow revision history to be retained when renaming/moving individual/multiple files AND renaming/moving folders w/ contents AND keep the current functionality(deletion specifically) intact. The main reason for this is that there are two separate "raw" events that get triggered when moving a file/folder...

1. "moved" event that contains the path for the previous location of the file/folder
2. "moved" event that contains the path for the new location of the file/folder

... and there is also a "moved" event triggered upon file deletion that contains the path from which the file was deleted.

There is no simple way to identify a direct link between the two events when moving a file/folder. My attempt was making the assumption that the events would always be triggered in order, but this may not always be the case(though it seems to be so far in my tests). Because there is no connection, it is not easy to identify, and because there is also a "moved" event triggered for unlink events, there is no way(that I can determine thus far) to accurately identify if a file has been moved, or if it has been deleted.

One other possible idea would be to utilize a timeout when the initial event is triggered and look for the subsequent event: if after a period of time the second event is not found, then it can be assumed that the file was deleted, and if it has been received, then we assume it was moved. We could make the call to the backend to delete the file wait until we receive a response for this, but the real problem is introducing a timeout. There are changes to files within the watch command such as switching branches that could see unintended side effects if a timeout is introduced to determine deletion/moved status, so I didn't spend time working on this.

@williamspiro

[miketalley]

I'm going to close this issue as I think the way that node events currently work makes creating a clean solution for this very difficult.