## Description
Pull request was made because of some user percentage has taskbar
connected on top, so it overlaps auth window for WinApp at start.
After some measuring, I found that taskbar occupies:
- 50px on FHD with 125% scaling (standard values on some notebooks)
- 40px on FHD with 100% scaling
- 30px on FHD with 100% scaling and small taskbar icons
## Description
### Background
Proposal to fix#4296 (@ua741). High level, there is a race condition
which is generating wrong entries in the FilesDB (creating orphan
files). This issue is easily replicable if you select multiple files and
try to download them (the more files, the more likely wrong entries will
be created). This issue is also messing up with the date of the files we
see in the timeline and is creating "orphan" (not linked to uploaded
files) files in the device collections.
To my understanding, this is quite a critical bug and any user is very
likely to encounter it in the current implementation.
There is some self healing already in place that will reupload all those
files and this should correct the dates, but this will only do it 10
files at a time, and based on potential candidates, without fixing the
orphan entries. I was also able to produce files which were never
corrected.
### This pull request
After extensive tests and lots of debugging, I was able to fully fix
this issue (meaning I am not able to reproduce it, at all, and I tried a
lot..). I also do not see any orphan in the device collection
("Pictures" folder for Android), while i could see 20+ (even more) each
time I was trying to replicate the issue. To fix it, I have:
- created a new class `PhotoManagerSafe` which is safely making sure
that the app will not react to file changes when it has been asked not
to do so (previous implementation allowed scenarios where a caller was
executing code thinking no change notification would be sent).
- created a Lock in the `LocalSyncService` that is used to make sure no
local synchronisation can be performed at the same time a download is
performed (this was the main culprit). The main side effect is that when
you download multiple files, they will be processed sequentially. I
think this can be improved but the main "side" advantage is that
whenever there is a failure, not a lot will be lost and it is more
robust in that way if you want to download a big collection. It would be
better to have at least 2 threads downloading/decrypting at the same
time, maybe (maybe not needed as well)?
- improved the "Downloading files..." dialog, which is now showing the
progress (for example "Downloading files... (235/494)"), so that the
user knows if something is actually happening and what is the current
progress.
- Added a missing call on the Video Editor page where the change notify
was stopped but never started again at the end when task was performed.
Feel free to close this PR if not suitable according to you, I can also
take feedback and try to implement them as best as I can.
## Tests
Tested on my Pixel 6a
Built with :
Flutter 3.24.3
JDK 17.0.2
Gradle 7.2
