propfind invalidates filecache

[winmillwill]

Before this change, we only serve from the file cache if the content was updated by a call to the server in the last 2 seconds, or the thread is in saint mode. The reason is that we do a conditional get using the If-None-Match header and the Etag from the last response for that file path, hoping to get a relatively fast 304 most of the time. However, querying total duration of requests broken down by cluster, method, and status shows that our 304 GETs are using just as much time in process as normal GETs and PUTs due to sheer volume.

This change invalidates the file cache for a path when a PROPFIND shows that the path has been updated in Valhalla. The mechanism for invalidation is to set the timestamp in filecache_pdata->last_server_update to 1 for the path in question, and to serve all paths from file cache if the entry isn't invalidated. This arrangement affords serving invalidated content while in saint mode, and aggressive removal of known invalid content by the file cache cleanup mechanism.

An optimization we could consider is to use the etag to locate the file cache content, in order to provide deduplication and potentially better cache coherency for the case where the same file content moves between paths. We would need to add the etag to the propfind data, parse it out, pass it to the callback, and use that to evaluate the freshness of the file cache data, and also change the logic for naming a cache file to rename the file after its hash is known, but before publishing file cache data to leveldb. Since the etag and the filename are both properties of the file cache data, we would need to either change the format of the stat cache data, add another entry type, or add a concept of "unfilled" file cache data.