Should REPO_REMOVAL_DELAY and the STALE_REMOVAL_DELAY be removed from GitLab
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=321716)
</details>
<!--IssueSummary end-->
## Summary
Are the REPO_REMOVAL_DELAY and the STALE_REMOVAL_DELAY, are those around solely for NFS?
Should they be removed from GitLab as they are now solely a Gitaly concern.
- https://gitlab.com/gitlab-org/gitlab/-/blob/d31e80e4d2acb2258ce3578964017a29e18e7d5b/app/services/repositories/shell_destroy_service.rb
Context from the original [Slack conversation](https://gitlab.slack.com/archives/CK75EF2A2/p1613380130109200):
> REPO_REMOVAL_DELAY and the STALE_REMOVAL_DELAY, are those around solely for NFS? Not advocating the removal, but wondering if this is a Gitaly concern more than a GitLab one.
> now that we have delayed project deletion more generally, I'd suggest it's outdated to have this as well, but I don't know the details
> would need a look in the overall context - it's used by Projects::DestroyService, for instrance, and it might be that it's enqueued early, before other actions that need the repository to still be around
> I excluded Repositories::* from my refactor that aimed to get rid of as much of the GitlabShellWorker stuff as possible last year, because it's a bit of a tangle and ISTR it's relied upon by geo as well
## Improvements
<!--
Explain the benefits of refactoring this code.
See also https://about.gitlab.com/handbook/values/index.html#say-why-not-just-what
-->
## Risks
<!--
Please list features that can break because of this refactoring and how you intend to solve that.
-->
## Involved components
<!--
List files or directories that will be changed by the refactoring.
-->
## Optional: Intended side effects
<!--
If the refactoring involves changes apart from the main improvements (such as a better UI), list them here.
It may be a good idea to create separate issues and link them here.
-->
## Optional: Missing test coverage
<!--
If you are aware of tests that need to be written or adjusted apart from unit tests for the changed components,
please list them here.
-->
<!--
Please select the appropriate label from the following:
~"feature::addition"
~"feature::maintenance"
~"tooling::pipelines"
~"tooling::workflow"
-->
issue