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

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

Bamboo & TeamCity Services: Fix missing credentials & URL handling

_Note: Originally opened at !4367 by @bentolor_

I've also fixed the URL handling for TeamCity which is very similar to Bamboo implementation-wise.

-----

*Note:* This is a port from my [original pull request on GitHub](https://github.com/gitlabhq/gitlabhq/pull/9428)

## What does this MR do?
This improves the Bamboo Service and provides two fixes:

1. One for the situation, where the build trigger won't work because Bamboo is requiring authentication credentials for the trigger GET: 8f25aca307b49ee006172b8c2985a878800aa6b6
2. One which fixes the way how the configured Bamboo base URL is assembled to the final REST URL. fe9eb30d7ebe4a83eefea7e06f8b69b135dad15d

### Regarding credentials
The change now does provide additional HTTP Basic Auth parameters if user credentials were provided and appends an request parameter indicating the HTTP Basic Authentication should be used. This aligns interaction with Bamboo with the other calls this service executes.

### Regarding URL handling
If one had configured a `bamboo_url` like http://foo.bar/bamboo in the previous implementation the plugin directed it's request i.e. to http://foo.bar/rest/... instead of http://foo.bar/bamboo/rest/...


## Are there points in the code the reviewer needs to double check?
The second issues was probably an unwanted side effect of how Ruby's `URI.join` is working. It will only work correctly, if 
- ... the prefix URL has at least one or more  trailing `/`
- .. the appendix parts are _not_ prefixed with `/`

I need try & figure it out using the rather lacking, official stdlib documentation and playing around in `irb`. As I'm an absolute Ruby novice I'm unable to add/provide new tests.

## Why was this MR needed?
Because Gitlab does not work in our Bamboo-Environment at all: Neither it is able to trigger Bamboo runs nor does the Merge status check work. This MR at least fixes the trigger issues.

## What are the relevant issue numbers?
This MR originates from my [original pull request on GitHub](https://github.com/gitlabhq/gitlabhq/pull/9428).
Sadly the issue, that the merge status is still not working correctly for branches will still not work. But at least the trigger works. 

There happened to be very much discussion about the branch status issue in #1355 and  #2562 though that one is lost as the author retracted his branch. 

See merge request !4408