Set expire_in for protected branch cache keys

What does this MR do and why?

Contributes to gitlab-com/gl-infra/scalability#1601 (comment 1010867339)

Problem

With default expiration settings 14 days, we consitantly generate records for each new version of the project in Redis but don't expire them.

Solution

Explicitly set 1 hour expiration TTL for cache keys. It should be sufficient for the original goal of making widget.json's source_branch_protected attribute load faster on subsequent loads... At the same time, keys will expire faster and won't be kept stale for 2 weeks.

Screenshots or screen recordings

Before

redis.ttl("cache:gitlab:protected_ref-projects/60-20220629152717684401-ba86e67d20d6cb8eb6833b19d314ac14745d4952") / 60.0
=> 20130.783333333333 (minutes)

After

redis.ttl("cache:gitlab:protected_ref-projects/67-20220622120643742325-728628cd15bf778bddfd2cc321707025bec67208") / 60.0
=> 59.4 (minutes)

How to set up and validate locally

Open Rails console

## Redis object
redis = Rails.cache.redis.with { |redis| redis }

## Search keys by project id
keys = redis.keys("cache:gitlab:protected_ref-projects/<project_id>*")

## Check ttl of the cache key
redis.ttl("cache:gitlab:protected_ref-projects/67-20220622120643742325-728628cd15bf778bddfd2cc321707025bec67208")

Numbered steps to set up and validate the change are strongly suggested.

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.