Cache vulnerability counts by day and severity information daily

Summary and context

The query for vulnerability counts grouped by day and severity is heavy. The database team has requested that it be cached.

Data is fetched in 10 day chunks, and used on both the group and instance security dashboards.

Caching on the old findings dashboard

Historical vulnerability data was also cached on the old findings dashboard. That code can be seen:

• Gitlab::Vulnerabilities::History
• Gitlab::Vulnerabilities::HistoryCache

In this implementation, history is cached per project.

Technical details

1. Redis can be used for caching the data
2. The cache must be busted daily to make sure the data is always up to date
3. A decision needs to be made around the cache key

Possible cache key

Cache the data in 10 day chunks for each project. A full response for 30, 60, or 90 days can be built from the 10 day chunks. A full response for both group and instance dashboard can be built from the different projects.

An advantage of this cache key is the ability to reuse a project cache for both a group and several instance dashboards.

A disadvantage is that it may require additional changes to the VulnerabilitiesHistoryResolver, and those changes must avoid introducing additional queries