Fix filecache scan deleting entries added by concurrent actions

[bduffany]

During the initial filecache scan, we repeatedly call AddFile() which calls lru.Remove().

The current implementation of AddFile() is:

1. Evict any existing entry. If an entry does exist, unlink it from the destination path, via the OnEvict callback.
2. Hardlink the file from the source path to its dest path.

For the filecache scan specifically, this logic is not ideal for two reasons:

• At best, it's unnecessary. We're effectively doing a bunch of hardlinks that just link each path to itself, which should be a NOP.
• At worst, an action can race with the filecache scan to update a cache key. If we call AddFile() during the scan, but an action was running concurrently and already called AddFile() for the same key, then step (1) above will invoke the OnEvict callback, which deletes the cache entry. Because we're linking the path from itself, the filecache scan sees a NotFound error when it tries to link this file. This is silly - if we hadn't deleted the entry, then it would be found.

[tylerwilliams]

this logic is a little confusing to me -- would it be clearer if we just enumerated the special case and unindented the rest?

if fp == existingFilePath && c.l.Contains(k) {
  return nil // skip adding the same file twice which could cause an eviction
}
c.l.Remove(k)
if err := disk.EnsureDirectoryExists(filepath.Dir(fp)); err != nil {
	return err
}
if err := cloneOrLink(groupID, existingFilePath, fp); err != nil {
	return err
}