[FEATURE REQUEST] Improve downloads behaviour, not depending on `Content-Length` header

[jesmrec]

It comes from #4352 (comment)

this is the way to do, following the line of iOS app:

By sending the Etag for the file from the last PROPFIND as If-Match header, the app can ensure it gets either:

• the version of the file whose metadata the app already has (=> which also means the size of the file is what the PROPFIND returned)
• or: a 412 status response indicating the file has changed in the meantime, so a PROPFIND on the file can be sent to update the metadata for the file and a download subsequently be re-attempted

Receiving a newer/different version of the file than what the last PROPFIND returned wouldn't be good for several reasons:

• the checksum verification (if one was provided by the server) would fail, which would make the app determine the file contents was not properly or fully received, and result in the app discarding the file it just downloaded
• the Etag would change for the file with the next PROPFIND (f.ex. while discovering changes), from the outdated one (at the time of download) to the actual one (for the file that was already downloaded). This would result in the app discarding the file it just downloaded - because it has to assume the file is has downloaded is a different version than the file on the server, due to the Etag change.

TASKS

• Research (if needed)
• Create branch feature/feature_name
• Development tasks
  • Implement whatever
  • ...
  • Implement unit tests (if needed)
• Code review and apply changes requested
• Design test plan
• QA
• Merge branch feature/feature_name into master

[jesmrec]

Check also de posibility of aligning Accept-Encoding: with other clients