Cache recent release items before enabling the feature flag that shows them in the menu bar

In !42494 (merged) we've added the ability to show a badge showing the number of new release items next to the What's new at GitLab menu in the top bar.

This is currently behind the whats_new_drawer that defaults to "off".

Before enabling the feature flag on GitLab.com, we should cache this information, so we don't need to read it from disk for every request.

---

The following discussion from !42494 (merged) should be addressed:

• @reprazent started a discussion: (+1 comment)

  This seems to be calling out to disk quite a lot:

  1. Once globbing the dir to get the most recent file name
  2. Once reading the file

  And both of these once for getting the count, and once for building the storage key.

  So perhaps we should cache this process wide in memory:

  Gitlab::ProcessMemoryCache.cache_backend.fetch("whats_new_most_recent_release_items:#{Gitlab.revision}") do
    Gitlab::Json.parse(whats_new_most_recent_release_items)
  end

  This would only require each process to read the file once an hour.

  I think we should then also use this cache in the view, rather than reading the file there as well.

  It isn't quite clear to me how often these release items would be accessed. If we're doing that on each request when the feature is enabled, would it be worth caching this on 2 levels? Roughly:

  Gitlab::ProcessMemoryCache.cache_backend.fetch("whats_new_most_recent_release_items:#{Gitlab.revision}") do
    Rails.cache.fetch("whats_new_most_recent_release_items:#{Gitlab.revision}") do
      Gitlab::Json.parse(whats_new_most_recent_release_items)
    end
  end

  That way, we only need to read the file once for each revision, and we'd reach out to redis if the items are cleared from the limited memory-cache.

  At this point I think it might be better to extract these methods out into a class that parses these files.

  What do you think?