Fix qa report from 1.16 beta: prevent reupload of every file

Description

Fix bug detected by QA eDrive force reuploading every file

Technical details

I expected nextcloud to provide remoteFile with timestamp in second (instead of ms) because, for upload, we have to convert file's last modified into second. In the end, RemoteFile.lastModified contains timestamp in ms. This fooled the check for corrupted timestamp.

In the same time, I removed forcing remoteFile.lastModified *1000 when storing file's data in DB. (Tests doesn't showed any differences).

So, when eDrive detect a remote file which has already be synchronized, and which has a last modified timestamp with a value equal to 2106-02-07 07:28:15 (4294967295 in ms) and with same eTag as the one in DB. Then it force re-upload, with valid timestamp.

It looks that some files got invalid timestamp a smaller but I choose to focus on this "4294967295" limit because it has programatical (it is max of uint32) meaning and thus it still allow user to sync file with date in futur if it is expected by him.

Tests

For the test you can generate a file with a corrupted timestamp by using the command touch -m -t 210602070728.15 <filename> or use this one: corrupted-timtestamp-example.md

Expected behaviour:

1. Already synced file with invalid timestamp (>= 4294967295000 ms) on cloud is overwritten with a normal date, if content of the file is the same on cloud & device.
2. Any other file with valid timestamp is not uploaded again each time
3. New file with invalid timestamp on cloud, is normally downloaded but the timestamp on the device is set to current time.

note: According to @diroots's comment in the issue, the goal is not to block the possibility to have a file with a date in futur. This is responsability of the user, and s.he may specifically want a file to have this kind of date. The goal is only to fix invalid date introduced by eDrive.

How to test:

1. Upload one file with corrupted timestamp in a directory. Let's say: /Photos/Camera/picture1.png FROM BROWSER
2. set up the account if not already done
3. Force sync or let sync
4. The file is downloaded into /DCIM/Camera/picture1.png

⚠ At this step, if you force sync or another sync happens, the file with invalid timestamp won't be corrected because there is no change on the parent folder that would lead eDrive to check for change in its content.

5. add a new file, change another file or remove another file in the directory where the invalid timestamp is stored on cloud
6. Force sync or let sync happens.

Expected: a sync request is generated to upload file with "corrected" timestamp to the cloud.

Example of logcat

File with invalid timestamp is "corrupted-timtestamp-example.md"

0-04 17:51:10.556  3034  6548 D OwnCloudClient #1: REQUEST PROPFIND /remote.php/dav/files/00020@eeo.one/Documents/
10-04 17:51:11.365  3034  6548 I ReadFolderRemoteOperation: Synchronized /Documents/: Operation finished with HTTP status code 207 (success)
10-04 17:51:11.366  3034  6548 V AbstractFileLister: added Capture d’écran du 2023-10-03 15-52-06.png into list of file to scan
10-04 17:51:11.366  3034  6548 V AbstractFileLister: added Capture d’écran du 2023-10-04 12-07-48.png into list of file to scan
10-04 17:51:11.367  3034  6548 V AbstractFileLister: added corrupted-timtestamp-example.md into list of file to scan
10-04 17:51:11.367  3034  6548 V AbstractFileLister: SyncedFolder : Images, /storage/emulated/0/Pictures/, 0, true, 5
10-04 17:51:11.371  3034  6548 D OwnCloudClient #1: REQUEST PROPFIND /remote.php/dav/files/00020@eeo.one/Pictures/
10-04 17:51:12.072  3034  6548 I ReadFolderRemoteOperation: Synchronized /Pictures/: Operation finished with HTTP status code 207 (success)
10-04 17:51:12.098  3034  6547 D ObserverService: onRemoteOperationFinish()
10-04 17:51:12.104  3034  6547 D RemoteContentScanner: manageSyncedFileStateDB( Capture d’écran du 2023-10-03 15-52-06.png, INSERT )
10-04 17:51:12.112  3034  6547 D SyncedFileStateDAO: Add downloadSyncRequest for new remote file: /Documents/Capture d’écran du 2023-10-03 15-52-06.png
10-04 17:51:12.113  3034  6547 D ObserverService: syncRequests contains 2
10-04 17:51:12.113  3034  6547 D SynchronizationService: startAllThreads
10-04 17:51:12.115  3034  6547 V CommonUtils: haveNetworkConnection()
10-04 17:51:12.121  3034  6547 V UploadFileOperation:  starts UPLOAD on thread #0 for: corrupted-timtestamp-example.md

Issues

e/backlog#6934 (comment 449223)

10 commandments of code reviews

👪 ❤ https://gitlab.e.foundation/internal/wiki/-/wikis/mobile-team/guidelines/Code-review