This is done to make belongs_to with required to properly validate association.
Otherwise `ActiveRecord::StatementInvalid` is raised.

# Conflicts:
#	db/schema.rb

Fix displaying of project settings links the user cannot access.

## What does this MR do?

It fixes the Project Settings dropdown displaying project settings links that the user cannot actually access.

## Are there points in the code the reviewer needs to double check?

I've tested combinations I can think of, feel free to mess around with and see if it breaks?

## Why was this MR needed?

Users were seeing links in the Project Settings dropdown that they shouldn't have seen, if they clicked them they would be shown permission errors.

## What are the relevant issue numbers?

#18294 

## Screenshots (if relevant)

Users without any permissions:

![Screen_Shot_2016-06-10_at_10.41.27_AM](/uploads/b70ca18a36b5f774b85694d8f1728882/Screen_Shot_2016-06-10_at_10.41.27_AM.png)

Guest members of the project:

![Screen_Shot_2016-06-10_at_10.48.36_AM](/uploads/a37986b4daa789063661c2fa8cf59d43/Screen_Shot_2016-06-10_at_10.48.36_AM.png)

Full permissions:

![Screen_Shot_2016-06-10_at_10.41.57_AM](/uploads/4c5cc97962e69a1a72ee8e237591ec22/Screen_Shot_2016-06-10_at_10.41.57_AM.png)

cc: @dzaporozhets @annabeldunstone @jschatz1 

See merge request !4599

Artifacts expire date

What do you think @grzesiek?

The syntax will be simple:
```
job:
  artifacts:
    expire_in: 7d
```

- [x] Implement `expire_in`
- [x] Check current design of expiry information with @jschatz1 and @markpundsack 
- [x] Add tests in GitLab application for a `ExpireBuildArtifactsWorker` and for `ArtifactsController::keep`
- [x] Add user documentation how to use `artifacts:expire_in`
- [x] Prepare GitLab Runner changes to pass `expire_in`: gitlab-org/gitlab-ci-multi-runner!191
- [x] Fix `timeago` with help of @jschatz1
- [x] Merge latest master after builds view changes @iamphill
- [ ] Add Omnibus support for `expire_build_artifacts_worker` cron job
- [ ] Add documentation how to configure `expire_build_artifacts_worker`

This is based on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4201.

See merge request !4200

Update CI API docs

Since CI is now part of GitLab, it makes sense to group all API related endpoints under
one location. This is a step towards the much awaited issue of doc restructure
https://gitlab.com/gitlab-org/gitlab-ce/issues/3349

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/18404

See merge request !4567

# Conflicts:
#	lib/ci/gitlab_ci_yaml_processor.rb

Fix timing issues on convertion migration award emoji

See merge request !4581

- Move ci/api under api/ci
- Clean up builds.md and runners.md
- Replace old links with new ones
- Add CI API links in ci/README.md

Measure CPU time for instrumented methods

See merge request !4640

Update CI Docker docs

## What does this MR do?

Updates documentation with:

* instructions for bind-mounting for docker runners (fixes #17769 and #13898)
* examples of using the GitLab Container Registry in docker-based builds (fixes #17968 and #17967)
* update runner instructions for `gitlab-ci-multi-runner` (fixes https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1337)
* some grammar fixes

## Are there points in the code the reviewer needs to double check?

The markdown in general. The runner commands. I haven't been able to verify the socket version works yet.

## Why was this MR needed?

Better documentation for users.

## What are the relevant issue numbers?
#17769, #13898, #17968, #17967 

## Screenshots (if relevant)

See merge request !4524

Add global entry with before script to new CI config

## What does this MR do?

This MR adds a new entries to a new CI config class. It is next refactoring step after !4462.

See #15060

See merge request !4482

Add whitelisted elements correctly in sanitization

Add whitelisted elements correctly in sanitization

Consider this command:

    bundle exec rails r "include GitlabMarkdownHelper
    puts markdown('<span>this is a span</span>', pipeline: :description)
    puts markdown('<span>this is a span</span>')"

And the same in the opposite order:

    bundle exec rails r "include GitlabMarkdownHelper
    puts markdown('<span>this is a span</span>')
    puts markdown('<span>this is a span</span>', pipeline: :description)"

Before this change, they would both output:

    <p><span>this is a span</span></p>
    <p>this is a span</p>

That's because `span` is added to the list of whitelisted elements in
the `SanitizationFilter`, but this method tries not to make the same
changes multiple times. Unfortunately,
`HTML::Pipeline::SanitizationFilter::LIMITED`, which is used by the
`DescriptionPipeline`, uses the same Ruby objects for all of its hash
values _except_ `:elements`.

That means that whichever of `DescriptionPipeline` and `GfmPipeline` is
called first would have `span` in its whitelisted elements, and the
second wouldn't.

Fix this by adding a special check for modifying `:elements` twice, then
checking `:transformers` as before.


See merge request !4588

MySQL apparently doesn't support executing multiple queries in the same
`execute` call so we have to use a separate one for the "LOCK TABLES"
statement.

As suggested by @yorrickpeterse in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4581#note_12373882
the locking of the MySQL database wasn't correct.

This commit does two things:
1. It adds logic which prevents timing issues when running the
migration. During the migration, notes can be created which _should_
be award emoji and thus migrated. To prevent these timing issues, a
lock is obtained on the table (MySQL) or on Transaction level (PG).
2. There was no down migration before as you'd probably lose some data.
Data effected is all awards on notes. These could be migrated back, as
the noteable type would just be Note, though this would litter the DB
with data which should not be there. This down migration does not yet
delete the table.

Allow users to create confidential issues in private projects

Closes #14787

## What does this MR do?

Allow users to create confidential issues in private projects, and exclude access to them to project members with `Guest` role.

## Are there points in the code the reviewer needs to double check?

The query generated by the `User#authorized_projects` method.

## Why was this MR needed?

Community have been requesting this feature.

## What are the relevant issue numbers?

https://gitlab.com/gitlab-org/gitlab-ce/issues/14787

https://gitlab.com/gitlab-org/gitlab-ce/issues/3678

## Screenshots (if relevant)

Not relevant.

## Todo

- [x] Allow users to create confidential issues in private projects
- [x] Project members with `Guest` role should not have access to confidential issues
- [ ] ~~Apply changes in EE + Elasticsearch~~ Will be done in another MR, when this got merged

See merge request !3471