Given no search term, the `search` and `search_with_secondary_emails` methods will yield an empty result set

Jan Christophersen authored 7 years ago and James Lopez committed 7 years ago

Resolve "Projects API: filter 'with_issues_enabled=true' returns projects with 'issues_enabled=false'"

with .public_send we can't make sure that the scope on the model
actually exists.

Adds `#build_notification_recipients` to `NotificationRecipientService`
that returns the `NotificationRecipient` objects in order to be able to
access the new attribute `reason`.

This new attribute is used in the different notifier methods in order to
add the reason as a header: `X-GitLab-NotificationReason`.

Only the reason with the most priority gets sent.

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] Migrate `can_push` column from `keys` to `deploy_keys_project`

See merge request gitlab/gitlabhq!2276

(cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c)

1f2bd3c0 Backport to 10.3

Remove order param from the MilestoneFinder

See merge request gitlab/gitlabhq!2259

(cherry picked from commit 14408042e78f2ebc2644f956621b461dbfa3d36d)

155881e7 Remove order param from the MilestoneFinder

Merge branch 'security-10-3-do-not-expose-passwords-or-tokens-in-service-integrations-api' into 'security-10-3'

Filter out sensitive fields from the project services API

See merge request gitlab/gitlabhq!2281

(cherry picked from commit 476f2576444632f2a9a61b4cead9c1077f2c81d7)

2bcbbda0 Filter out sensitive fields from the project services API

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.

Previously, the last push widget would only show when the branch never had
a merge request associated with it - even merged or closed ones. Now the
widget will disregard merge requests that are merged or closed.

Closes gitaly#915

Closes #41633

This should reduce the number of SQL queries and lookups needed to look up a
project of a build and pipeline and vice versa.

Before:

```
[1] pry(main)> Ci::Build.reflect_on_association(:project).has_inverse?
=> false
[2] pry(main)> Project.reflect_on_association(:builds).has_inverse?
=> false
[3] pry(main)> Ci::Pipeline.reflect_on_association(:project).has_inverse?
=> false
[4] pry(main)> Project.reflect_on_association(:pipelines).has_inverse?
=> :project
```

After:

```
[1] pry(main)> Ci::Build.reflect_on_association(:project).has_inverse?
=> :builds
[2] pry(main)> Project.reflect_on_association(:builds).has_inverse?
=> :project
[3] pry(main)> Ci::Pipeline.reflect_on_association(:project).has_inverse?
=> :pipelines
[4] pry(main)> Project.reflect_on_association(:pipelines).has_inverse?
=> :project
```

If we search for notes before the MR was merged, we have to load every commit
that was ever part of the MR, or mentioned in a push. In extreme cases, this can
be tens of thousands of commits to load, but we know they can't revert the merge
commit, because they are from before the MR was merged.

In the (rare) case that we don't have a `merged_at` value for the MR, we can
still search all notes.

with StrongMemoize

This reverts commit 3576d59a.

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

Closes #41739

This reverts commit 8040edcc.