GitLab Version - Increase ReactiveCache life

What does this MR do and why?

Related to #352355 (closed)
Follow up for !73504 (merged)

This change extends the cache refresh interval and cache lifetime for the VersionCheck Reactive Cache. More can be read about these properties here: https://docs.gitlab.com/ee/development/reactive_caching.html#selfreactive_cache_lifetime

What is version check?

We provide upgrade information in relation to a customer's GitLab instance via the Version Check Application. This is what powers the GitLab version badge that is found in the following three locations:

1. The Help Page (/help)
2. The Admin Dashboard (/admin)
3. The Nav Bar Help Dropdown (Question mark in the top right of the top nav)

The way that it works is the customer's instance sends an external api request to http://version.gitlab.com/check.json with some encoded data and receives an API response that informs them if there is a Instance Upgrade available.

Example API response:

  {
    "latest_version": "15.2.2",
    "severity": "success"
  }

This response is then stored in ReactiveCache so that we aren't constantly sending External API requests for a response that won't change unless one of the following conditions are met:

1. Customer upgrades their GitLab Instance
2. GitLab releases a new version

Additionally in scenario 1, the Gitlab::VERSION is used as the cache identifier so if the customer upgrades it invalidates the cache and will require a fresh pull. So in 99% of scenarios the API response will be exactly the same between requests. Further emphasizing the need for a long lived cache.

The problem

Inherently with ReactiveCache the very first request will return nil while the cache creates a job to fetch the data. This is solved by a page refresh. This is a tad annoying but tied together with a long cache life this should have minimal impact on the customer.

However, by default ReactiveCache only has a 10 minute life and refreshes itself every 1 minute in the background. So currently every instance that uses this feature will experience this:

1. Hits page with Version Check Badge
2. Nothing shows up because cache is empty and job is created
3. Refreshes page
4. Badge is there now yay!
5. Cache then is updated every minute for the next 10 minutes (cache lifetime) via the external API call
6. Cache invalidates after those 10 minutes (assuming user doesn't refresh or revisit again)
7. Next time user hits the page the whole process restarts

So as you can see we have both a too short lived cache accompanied by an unnecessary rigorous refresh interval.

This MR extends those values out to now instead storing the cache for 7 days and refreshing behind the scenes every 12 hours.

Screenshots or screen recordings

N/A

How to set up and validate locally

To see the cache invalidation happening to fast

1. Checkout master
2. Click the Help Dropdown in the top right ? of the nav
3. Ensure you see "Your GitLab version" but no badge
4. Refresh
5. Repeat and you should now see the badge
6. Wait 10+ minutes
7. Refresh the page and click the dropdown, the badge should no longer be there

To see the long lived

1. Checkout this branch
2. Click the Help Dropdown in the top right ? of the nav
3. Ensure you see "Your GitLab version" but no badge
4. Refresh
5. Repeat and you should now see the badge
6. Wait 10+ minutes
7. Refresh the page and click the dropdown, the badge should still be there

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

cc/ @jayo thank you so much for the help on this 🙇
cc/ @DylanGriffith for visibility since we worked on this initially together 👀