improve files cache

[ThomasWaldmann]

We can build the files cache by reading the "previous" archive from the repo after we have the "backup series" feature (#8379 is merged), see:

#7930 (comment)

Pros:

• saves local disk space of the files cache
• no need to "persist the files cache" (the "previous archive" is persisted anyway)
• the archive always has mtime AND ctime (our files cache implementation only stores one of them)
• we do not need the exclusive lock on the cache, because there is no read-modify-write on the files cache anymore. that would give us parallel borg create by default (without the BORG_CACHE_IMPL=adhoc hack).
• we can get rid of some parts of the files cache code related to locking and persistence

Cons:

• querying the previous archive's metadata stream from the repo and building an "in-memory files cache" is likely slower than loading the files cache from disk
• supporting "generations" / "TTL" would even mean to query multiple "previous archives" from the repo. guess that isn't worth the effort, so we'll just try with the latest one.

[ThomasWaldmann]

@intelfx noted on IRC that this might be a bit much traffic if the archive is e.g. 5M files big.

True, so guess this will need some optimization afterwards, e.g. persisting the files cache or the archive metadata stream locally.

[ThomasWaldmann]

Guess we could do it like that:

• before create: load the files cache for this archive series from local cache
• if that fails (because there is no local cache), try rebuilding it from previous archive
• end of create: save the files cache for this archive series to local cache

Update: Done!

Now usually there is no transfer from repo needed. But that can be done in case the local files cache is lost (still better than re-reading/chunking/hashing everything).

Local "files cache" filename suffix automatically determined by archive (series) name or manually via the env var by the user. Now mtime AND ctime stored in the files cache.