Delta propfind

As discussed with @juliushaertl we had following idea.
Problem:

• have a folder with 5k folders
• add/change/delete one file
• etag changes
• client issues propfind to server: receive a list of 5k +/-1 file
• client needs to update entire local database

Solution would be now

• add a new column to filecache_extended: last_change_time
• server stores for every file change and file creation current timestamp
• client sends propfind with their last_change_time, e.g. 1690298793 (unix time stamp)
• server can check for content of this folder which children have been changed/created and return only them
• for deletion this obviously cannot work, as entry in filecache_extended is deleted
  • thus our idea is to store this as a "transaction log" for some time (e.g. 2 days)
  • if clients sends a too old timestamp, then server replies with custom status and sends entire content

Start by tracing the server handling for PROPFIND and the filecache_extended data mentioned in the issue. Review how file creation, changes, and deletions are recorded, then define how a client timestamp selects incremental results and when the server must return the full folder contents. Done means changed and created children are returned incrementally, deletions remain discoverable through a temporary transaction log, and old timestamps trigger a full response.