Also:
- Changes scopes from serializer to use boolean columns
- Fixes broken specs

Includes:
- Model, factories, create service and controller actions
- As usual, includes specs for everything
- Builds UI (copy from PAT)
- Add revoke action

Closes #31591

[10.6] Prevent notes on confidential issues from being sent to chat

See merge request gitlab/gitlabhq!2366
# Conflicts:
#	app/helpers/services_helper.rb

This removes the column that was added in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15670 since we
will no longer be allowing _permanent_ redirects

Closes #44467.

Closes #23460

Closes #28857

Server Side Request Forgery in Services and Web Hooks

See merge request gitlab/gitlabhq!2337

Closes #44446.

We still have >100K unmigrated MergeRequestDiffs
which don't have commits_count set yet (see
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17567#note_61904891)

This migration re-schedules the original background migration.
To assure that records are not processed twice, records with
commits_count set are skipped.

Related to #41698 and !17567

This was causing user deletions to time out.

Closes #44008

API requests were timing out because `tag_id` was missing an index. These
migrations were imported by running https://github.com/mbleigh/acts-as-taggable-on#post-installation:

```
bundle exec rake acts_as_taggable_on_engine:install:migrations
```

It looks like the `acts-as-tagglable` gem added the indexes in v4.0.0, but
when we upgraded from v3.5.0 (back in 2016 via
f571aeb5) we did not add them.

On staging, there are about 10.7 million rows on the `taggings` table. It took about 30 seconds for each index to be created.

On production, there are about 17.4 million rows, so I suspect the time to be about a minute per index.

Closes #43927

Closes #43802

This flag will allow maintainers of a project to push to specific
branches of a fork of a project

Integrate two workers into one ArchiveTraceWorker with pipeline_background queue. This queue takes loqer precedence than pipeline_default.

This is to avoid a mix-up with the existing concept of 'user
contributions'. See `User#contributed_projects` or
`Event#contributions`.