Retention of Symbol packages and files

[chriseldredge]

Currently symbol packages can be pushed but there is no method of removing old symbol packages and related files. As a Klondike instance is used, the symbol directory can grow in disk usage.

Klondike should track access to symbol data in a similar way to how upload date and download counters are tracked for normal packages. This would allow an administrator to identify symbols that have never been used and are older than a given period of time.

Since Klondike processes symbols through Windows Tools for Debugging and some symbol files may be identical between different symbol packages, additional metadata needs to be tracked that links symbol files to packages. When a symbol package is deleted, a reference counter can be used to delete symbol files that are linked to zero packages.

To simplify retention, the option to eagerly unzip source files from a symbol package onto disk should be removed.

For advanced scenarios, administrators may want to retain symbols for packages that have been deployed to a production environment.

• [ ] Remove ability to eagerly unzip symbol package contents
• [ ] Create new Lucene.Net index of symbol package metadata (file path, list of symbol files generated from package, upload date, access date)
• [ ] When a source file is downloaded, increment a metadata counter for the corresponding package
• [ ] Expose WebApi methods to query symbol index to find packages that were uploaded before or after a given date, when a package was last accessed or when a package was uploaded
• [ ] Expose WebApi method to delete symbol packages by Id and Version, or by query.
• [ ] Expose WebApi method to explicitly set retention policy for packages that should be kept.