feat(handlers): add code path to check ongoing rename

What does this MR do?

Relates to #925 (closed)

Adds code to check redis if a rename of a repository tied to a GitLab project is in progress and block (if applicable) any blob, tag and manifest uploads and deletes for the GitLab project.

This new code path will only be triggered once the feature toggle introduced in !1328 (merged) is toggled on in Enable Repository lease check in gstg, pre and ... (#1036 - closed) . However, even with the toggle on, only the check against redis will be carried out. The decision to block a request will never be enforceable with the feature deployed until we have tackled #924 (moved) to allow rails to enact a rename (hence causing a block)

☣ This feature will be applicable only to registry users of both metadata database & redis (i.e. .com for now). The feature flag gating this feature, once toggled will necessitate that: the registry redis be always functioning accordingly in order for pushes to the registry be completed successfully (Update: Pushes will continue if redis is down to avoid impactful degradation on the registry and instead an error will be thrown, see discussion here). This is because we will now exclusively need to check redis to confirm there are no blocks on a repository due to an ongoing rename ☣

The rollout will be tracked in Enable Repository lease check in gstg, pre and ... (#1036 - closed)

Author checklist

• Feature flags
  • Added feature flag:
  • This feature does not require a feature flag
• I added unit tests or they are not required
• I added documentation (or it's not required)
• I followed code review guidelines
• I followed Go Style guidelines
• For database changes including schema migrations:
  • Manually run up and down migrations in a postgres.ai production database clone and post a screenshot of the result here.
  • If adding new queries, extract a query plan from postgres.ai and post the link here. If changing existing queries, also extract a query plan for the current version for comparison.
  • Do not include code that depends on the schema migrations in the same commit. Split the MR into two or more.
• Ensured this change is safe to deploy to individual stages in the same environment (cny -> prod). State-related changes can be troublesome due to having parts of the fleet processing (possibly related) requests in different ways.

Reviewer checklist

• Ensure the commit and MR tittle are still accurate.
• If the change contains a breaking change, apply the breaking change label.
• If the change is considered high risk, apply the label high-risk-change
• Identify if the change can be rolled back safely. (note: all other reasons for not being able to rollback will be sufficiently captured by major version changes).

If the MR introduces database schema migrations:

• Ensure the commit and MR tittle start with fix:, feat:, or perf: so that the change appears on the Changelog

If the changes cannot be rolled back follow these steps:

• If not, apply the label cannot-rollback.
• Add a section to the MR description that includes the following details:
  • The reasoning behind why a release containing the presented MR can not be rolled back (e.g. schema migrations or changes to the FS structure)
  • Detailed steps to revert/disable a feature introduced by the same change where a migration cannot be rolled back. (note: ideally MRs containing schema migrations should not contain feature changes.)
  • Ensure this MR does not add code that depends on these changes that cannot be rolled back.