fix(#634): Reduce data bandwidth for non-comliant WebDAV servers 📉

Up to now, we sync libraries in the background about every 15mins. This is okay, assuming that in 90% of all sync attempts, we need a single HTTP call to find out that actually, no data needs to be pulled from the server.

However, for some non-compliant WebDAV servers, this isn't the case. Actually, WebDAV defines that eTags (properties on files and folders that tell us if there was an update on the server) shall be recursive on folder level. If they are, we need a single HTTP call on the top level folder to find out if we need to continue checking further sub-folders. However, some non-compliant servers don't provide recursive eTags. For such servers, we use a workaround where we recursively check all folders on the server side for updates. Consequentially, the number of HTTP calls (and hence, the minimum required bandwidth for a sync) multiplies with the number of folders that are in a library.

To reduce the amount of data downloaded in the background, we now use a custom sync interval for such non-compliant servers - in such cases, we check only every 2 hours for server side updates. This should bring down the bandwidth used by the app dramatically.

Note that this does not affect syncs that are triggered while the app is in use (i.e. by creating new items locally or editing existing ones). As always, in such cases a sync will be triggered immediately to ensure that the changes get published as soon as possible.

Closes #634 (closed)