Upload-overlay is slow and not robust

[tbsbdr]

Steps to reproduce

1. Download und unpack Linux Kernel 5.17.8 : https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.17.8.tar.xz
2. Login to https://ocis.ocis-wopi.released.owncloud.works/
3. select "Upload" > "Folder" "linux-5.17.8/arch/arm64" (1.741 items, 12.75 MB)
4. wait until List "XX uploads completed" shows up
5. XX counts up and gets slower until it stops completely.

2022-05-30_11-15-27.mp4

Expected behaviour

• upload overlay should not stop working for upload of many files (> 1.000 files). Please stresstest with linux-kernel files (Note: final goal is, that the upload of the whole linux kernel should be possible with 1.1 GB and ~80.000 files)
• Simple overlay that tells me if the upload is
  • In progress
  • Completed
  • Failed
• possibility to show details of the upload

Simple overlay:

Details overlay

The scribble shows

• progress per single file
• cancel per single file
  --> both info would be nice to have, but are costly to implement. So @JammingBen and I discussed to tackle this nice-to-have not within this ticket.
  --> Details-Scribble is subject to change until we know how to tackle the performance issue in the upload process.

Simplified time format

• upload estimation time should be simplified (rounded)
• mocks show a proposal - imo can be adapted if rounding-functions already exist

Actual behaviour

• upload overlay stops working if many files are getting uploaded.

[tbsbdr]

@JammingBen any new insights where the performance bottle necks are? If yes, we should talk about what solution we can provide with cost/benefits in mind.

[tbsbdr]

@JammingBen in the scribble i used a "counter-clockwise" orientated arrow but noticed now in your draft, that this is confusing.
i google "retry icon" and most icons are clockwise orientated - I recommend to use the "restart" icon from remixicons for the retry-action:

[tbsbdr]

added "Simplified time format" to initial comment

[JammingBen]

Things have gotten a lot better with the recent updates, uploading the Linux Kernel is still not possible though. Next steps towards this:

• Use the Create with upload extension to save up one request. That's not working out of the box and needs debugging in the tus-js-client first -> tackled via Use 'uploadDataDuringCreation' option when uploading via tus #7111
• Implement the possibility in oCIS to create non existing folders "on the fly" rather than creating the folder structure beforehand.