Closes gitaly#921

Closes gitaly#929

Search query is especially slow if a user searches a generic string
which matches many records, in such case search can take tens of
seconds or time out. To speed up the search query, we search only for
first 1000 records, if there is >1000 matching records we just display
"1000+" instead of precise total count supposing that with such amount
the exact count is not so important for the user.

Because for issues even limited search was not fast enough, 2-phase
approach is used for issues: first we use simpler/faster query to get
all public issues, if this exceeds the limit, we just return the limit.
If the amount of matching results is lower than limit, we re-run more
complex search query (which includes also confidential issues).
Re-running the complex query should be fast enough in such case because the
amount of matching issues is lower than limit.

Because exact total_count is now limited, this patch also switches to
to "prev/next" pagination.

Related #40540

This fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38634.

Closes #42249

Gitlab::Profiler.profile takes a URL to profile, and returns the ruby-prof
profile result.

This is currently only for interactive use (in a console) or from the script
runner. Note that when using this interactively, changes to the application
within that console session will be used, so this can be used to test proposed
performance changes.

Prior to this commit we would essentially update all rows in a table,
even those where the source column (e.g. `issues.closed_at`) was NULL.
This in turn could lead to statement timeouts when using the default
batch size of 10 000 rows per job.

To work around this we don't schedule jobs for rows where the source
value is NULL. We also don't update rows where the source column is NULL
(as an extra precaution) or the target column already has a non-NULL
value. Using this approach it should be possible to update 10 000 rows
in the "issues" table in about 7.5 - 8 seconds.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/42158

The performance bar is still displayed by default in development.

Signed-off-by: Rémy Coutable <remy@rymai.me>

[10.3] Prevent login with disabled OAuth providers

See merge request gitlab/gitlabhq!2296

(cherry picked from commit 4936650427ffc88e6ee927aedbb2c724d24b094c)

a0f9d222 Prevents login with disabled OAuth providers

[10.3] Fix RCE via project import mechanism

See merge request gitlab/gitlabhq!2294

(cherry picked from commit dcfec507d6f9ee119d65a832393e7c593af1d3b2)

86d75812 Fix RCE via project import mechanism

Merge branch '41293-fix-command-injection-vulnerability-on-system_hook_push-queue-through-web-hook' into 'security-10-3'

Don't allow line breaks on HTTP headers

See merge request gitlab/gitlabhq!2277

(cherry picked from commit 7fc0a6fc096768a5604d6dd24d7d952e53300c82)

073b8f9c Don't allow line breaks on HTTP headers

[10.3] Fix path traversal in gitlab-ci.yml cache:key

See merge request gitlab/gitlabhq!2270

(cherry picked from commit c32d0c6807dfd41d7838a35742e6d0986871b389)

df29094a Fix path traversal in gitlab-ci.yml cache:key

[10.3] Fix XSS vulnerability in Pipeline job trace

See merge request gitlab/gitlabhq!2258

(cherry picked from commit 44caa80ed9a2514a74a5eeab10ff51849d64851b)

5f86f3ff Fix XSS vulnerability in Pipeline job trace

A file containing /:\d+:/ in its contents would break the search results if
those contents were part of the results, because we were splitting on colons,
which can't work with untrusted input.

Changing to use the null byte as a separator is much safer.

Closes gitaly#915

Closes gitaly#907

Closes #41633

with StrongMemoize

Closes gitaly#851

For each MR diff an extra 'SELECT COUNT()' is executed
to get number of commits for the diff. Overall time to get counts for
all MR diffs may be quite expensive. To speed up loading of MR info,
information about number of commits is stored in a MR diff's extra column.

Closes #38068