Allow service account to have deploy keys
<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab.
The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). -->
## Release notes
<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
## Problem to solve
Sometimes [Deploy Keys](https://docs.gitlab.com/ee/user/project/deploy_keys) causes a confusion that the key doesn't work in certain condition, for example, git-push fails by [protected branches/tags](https://gitlab.com/gitlab-org/gitlab/-/issues/329742). This is because GitLab evaluates the **creator** of the deploy key if the person has permission to access to the Git-Ref and subsequent processes, such as pipeline runs.
However, the point of Deploy Keys is to treat it as **an individual machine user**, so that it should NOT be affected by the creator of the deploy key. For example, deploy keys should keep working even after the creator of the deploy key removed from the project.
<details><summary>Original bug report (later changed to feature request)</summary>
## Summary
Deploy Keys has `user_id`:
```
gitlabhq_production=# select id, user_id, title from keys where type LiKE 'DeployKey';
id | user_id | title
----+---------+-------------------------------------------
48 | | jenkins@test12 <- old key (no user_id)
57 | 73 | srv (legacy key) <- new key (has user_id)
```
## Steps to reproduce
Create new Deploy Key for the project.
### What is the current *bug* behavior?
We have a user name in output:
```
$ ssh -T git@gitlab -i ~/.ssh/srv
Welcome to GitLab, Borys Borysenko!
```
## What is the expected *correct* behavior?
No user name in output:
```
$ ssh -T git@gitlab -i ~/.ssh/id_rsa
Welcome to GitLab, Anonymous!
```
### Results of GitLab environment info
```
[root@gitlab ~]# gitlab-rake gitlab:env:info
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.3.3p222
Gem Version: 2.6.6
Bundler Version:1.13.7
Rake Version: 10.5.0
Redis Version: 3.2.5
Git Version: 2.13.0
Sidekiq Version:5.0.0
Go Version: unknown
GitLab information
Version: 9.3.9
Revision: 755bb71
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: https://gitlab.owox.com
HTTP Clone URL: https://gitlab.owox.com/some-group/some-project.git
SSH Clone URL: git@gitlab.owox.com:some-group/some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 5.1.1
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git
```
### Results of GitLab application Check
Everything is ok (green).
</details>
## Usecase
As a GitLab administrator, I want to manage GitLab users independently of deploy keys. The users are an organizational topic, while the deploy keys are an operational topic. The two should not be tied together.
## Proposal
GitLab now has [the first-class service account](https://docs.gitlab.com/ee/user/profile/service_accounts.html) feature, but it can only [create PAT](https://docs.gitlab.com/ee/api/groups.html#create-personal-access-token-for-service-account-user) today.
We should allow SA to have [Deploy Keys](https://docs.gitlab.com/ee/user/project/deploy_keys/) as well.
## Intended users
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/product/personas/#sidney-systems-administrator)
* [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
## Feature Usage Metrics
<!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
-->
## Related
- https://gitlab.com/groups/gitlab-org/-/epics/6777+
- https://gitlab.com/groups/gitlab-org/-/epics/2587#note_694484465
- https://gitlab.com/gitlab-org/gitlab/-/issues/339873
issue