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

This change is required because otherwise if a user is created with a
value for `projects_limit` that matches the DB default, it gets
overwritten by `current_application_settings.default_projects_limit`. By
removing the default we once again can allow a user to be created with a
limit of 10 projects without the risk that it'll change to 10000

(10.2) Avoid partial partial email adresses for matching

See merge request gitlab/gitlabhq!2232

(cherry picked from commit 081aa1e91a777c9acb31be4a1e76b3dd7032fa9a)

There are unresolved conflicts in app/models/user.rb.

fa85a3fd Don't allow searching for partial user emails

By caching the number of personal SSH keys we reduce the number of
queries necessary on pages such as ProjectsController#show (which can
end up querying this data multiple times).

The cache is refreshed/flushed whenever an SSH key is added, removed, or
when a user is removed.

These dropdown options are used for creating and transfering projects.

By using SQL::Union we can return a proper ActiveRecord::Relation,
making it possible to select the columns we're interested in (instead of
all of them).

Replaces all the explicit include metadata syntax in the specs (tag:
true) into the implicit one (:tag).
Added a cop to prevent future errors and handle autocorrection.

The helper creates a fork of a project with all provided attributes,
but skipping the creation of the repository on disk.

and rubocop fixes

a reconfirmation

make sure it stays confirmed

This reverts merge request !14148

Revert "Merge branch '35012-navigation-add-option-to-change-navigation-color-palette' into 'master'"

This reverts merge request !13619

Whenever you push to a branch GitLab will show a button to create a
merge request (should one not exist already). The underlying code to
display this data was quite inefficient. For example, it involved
multiple slow queries just to figure out what the most recent push event
was.

This commit changes the way this data is retrieved so it's much faster.
This is achieved by caching the ID of the last push event on every push,
which is then retrieved when loading certain pages. Database queries are
only executed if necessary and the cached data is removed automatically
once a merge request has been created, or 2 hours after being stored.

A trade-off of this approach is that we _only_ track the last event.
Previously if you were to push to branch A and B then create a merge
request for branch B we'd still show the widget for branch A. As of this
commit this is no longer the case, instead we will only show the widget
for the branch you pushed to most recently. Once a merge request exists
the widget is no longer displayed. Alternative solutions are either too
complex and/or too slow, hence the decision was made to settle for this
trade-off.

Performance Impact
------------------

In the best case scenario (= a user didn't push anything for more than 2
hours) we perform a single Redis GET per page. Should there be cached
data we will run a single (and lightweight) SQL query to get the
event data from the database. If a merge request already exists we will
run an additional DEL to remove the cache key.

The difference in response timings can vary a bit per project. On
GitLab.com the 99th percentile of time spent in User#recent_push hovers
between 100 milliseconds and 1 second, while the mean hovers around 50
milliseconds. With the changes in this MR the expected time spent in
User#recent_push is expected to be reduced down to just a few
milliseconds.

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