Poor performance in GitLab::RepositorySetCache#read on projects with huge tag sets

At present, the Gitlab::RepositorySetCache#read method on GitLab.com experiences very poor performance on projects with very large sets of branches and tags (notably, GitLab's own major repositories).

The number of slowlog entries being recorded on Redis cache spiked following the release of this change.

(Note that for small tag/branch sets, the original !17116 (merged) change is vastly better than the old Rails.cache approach})

gitlab-com/www-gitlab-com#5708 (closed)
!17116 (merged)
!19572 (closed)
!19125 (merged)
!19573 (merged)

Capacity Planning dashboard search: redis-cache/single_threaded_cpu

cc @nick.thomas