When a user requests a Git archive, the resulting file is cached
in `Gitlab.config.gitlab.repository_downloads_path` by Workhorse
and cleaned up by the `RepositoryArchiveCleanUpService`, which runs
as a cronjob every hour.

However, on multi-node systems where Sidekiq and Workhorse are
on different nodes, `Gitlab.config.gitlab.repository_downloads_path`
may not be a shared volume. As a result, Sidekiq will not see any
stale files in that path, while archives build up over time.

Previously admins must make this a shared path for this to work, but
this introduces a single point of failure and more configuration to
get right. Alternatively, they can disable the cache.

Instead we observe that because Workhorse writes these files, we
can also have Workhorse clean the path periodically.

To avoid having to set a configuration variable, Workhorse gets the
`StoragePath` upon an archive request, which then initiates the
cleaner to run. However, this has the downside of requiring a single
user request to initiate the cleaning, but the tradeoff seems worth
it. We can always add the path as a configuration parameter later.

Relates to https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6005

Changelog: fixed