RE2 differs from Ruby in handling multiple-line strings. The string "foo\n"
will not match the regular expression "foo$" unless multi-line mode is enabled
(and it's off by default).

Since we're already scanning the build trace line by line (and so multi-line
coverage regular expressions won't work), we can fix this by removing the line
separator before scanning the string.

Fix an infinite loop in Gitlab:UntrustedRegexp

See merge request !2146

First commit in probably 2, for resolve gitlab-org/gitlab-ce#15582. This
commit is renaming files and classes from build to pipeline. Also
wording is editted to pipeline. Given `pipeline` had more characters
than `build`, I've made the field a bit wider. The width now matchers
the one for the coverage badge, so they look nice when in a table
format, or in a list.

As soon as this commit is merged to master, and released, the build.svg
is deprecated, meaning that all users which already placed a badge
should update it. However, to make sure it keeps working tests are added
for this case.

Closes gitaly#396

24570 use re2 for user supplied regexp 9 3

See merge request !2129

We also try to use instance variable to cache the result if
RequestStore is not available, so we could keep the same logic,
using the same cache key. Also introduce a way to specify method
specific cache key

I don't like the idea of `RequestStore` at all, because it's just a
global state which shouldn't be used at all. But we have a number of
places calling `ProtectedBranch.protected?` and `ProtectedTag.protected?`
in a loop for the same user, project, and ref whenever we're checking
against if the jobs for a given pipeline is accessible for a given user.
This means we're effectively making N queries for the same thing over
and over.

To properly fix this, we need to change how we check the permission,
and that could be a huge work. To solve this quickly, adding a cache
layer for the given request would be quite simple to do.

We're already doing this in Commit#author, and this is extending that
idea and make it generalized.

Simply re-raise an exception when it occurs, but guarantee that no
background migration is lost in the process.

It also makes it possible to gracefully retry a migration in order to
avoid problems like deadlocks.

We first pop a job from the Sidekiq queue / scheduled set and only if
this has been successfully deleted we process the job. This makes it
possible to minimize a possibility of a race condition happening.

When sign-in is disabled:
 - skip password expiration checks
 - prevent password reset requests
 - don’t show Password tab in User Settings
 - don’t allow login with username/password for Git over HTTP requests
 - render 404 on requests to Profiles::PasswordsController

Otherwise some features would go untested in non-specific contexts

I did need to disable the
`gitlab_git_diff_size_limit_increase`-feature in some specs since we
depend on diffs being expandable while the file we are testing on is
smaller than the increased limit.