When a deploy key is presented to the initial auth check, a temporary
LFS deploy token is assigned to the request, regardless if the user has
access to the project.

When the LFS client presents this token,
`Gitlab::Auth::Result#lfs_deploy_token?` returns `true` if the deploy
key has access to the project. If it does, then the LFS auth check
succeeds, and LFS downloads proceed normally.

However, if `Gitlab::Auth::Result#lfs_deploy_token?` returns false,
`LfsRequest#lfs_download_access?` will then call
`user_can_download_code?` to check if the given deploy key has access to
download the repository code.

The introduction of
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62733 assumed that
anything passed to `ProjectPolicy` would include the `PolicyActor`
module. Since `DeployKey` did not, the auth check would fail with
`undefined method from_ci_job_token?`.

We fix this by delegating the `PolicyActor` methods to the user and
adding specific policies in `ProjectPolicy` for deploy keys to read or
write to a repository.

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/334910

Changelog: fixed