GitLab EE adds an extra relation that selects a "project_id" column
instead of an "id" column, making it very hard for this method to be
re-used in EE. Since using User#authorized_groups in
ProjectsFinder#all_groups apparently has no performance impact we can
just use it and keep everything compatible with EE.

fix token issue - timing attack

Updates token comparisons to use a secure version instead of `==`

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

See merge request !3062

# Conflicts:
#	app/helpers/application_helper.rb

Fix responsive bug top navigation

Hi,

I have found and fixed a minor layout bug (responsive)

This is the situation before the fix:
![before](/uploads/55bf61a64fb49a763c5f8381bf46d390/before.png)

And this is the situation after the fix:
![after](/uploads/33ba091156d404e52c41f134121c59f0/after.png)

See merge request !3190

Use a custom Devise failure app to handle unauthenticated .zip requests

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/12944

See merge request !2828

Refactor searching and use PostgreSQL trigram indexes for significantly
improved performance

Related issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/13743.

Also fixes #12410

See merge request !2987

This explains the user what they need to run and where to go in case
they want to learn more about "CREATE EXTENSION".

The OR condition for source_project_id/target_project_id leads to a
query plan that performs rather poorly on PostgreSQL due to the use of
sub-queries. Because Rails offers no easy alternative for this
particular problem we're forced to using a UNION for both conditions.
The resulting query performs much faster than just using an OR.

This ensures searching namespaces works exactly the same as searching
for any other resource.

We can just use "arel_table" in these cases instead of
"SomeClass.arel_table".

We don't need the extra layer of nesting of UNION queries here (as
User#authorized_projects already returns a UNION'd query).

There's no need to order queries used as sub-queries and doing so can
add potential overhead.

This ensures some other methods such as the "issues" method still work.

This spec was still passing an ID to the #initialize method instead of
a Project instance.

This code is mostly a copy-paste from existing pull requests so there's
no point in running Rubocop on it.

This ensures that options such as `using: :gin` and PostgreSQL operator
classes are ignored when loading a schema into a MySQL database.

This also includes e.g. the appearances table which apparently wasn't
already included in the schema.

This is needed to support creating/dumping/loading indexes that use the
gin_trgm_ops operator class on PostgreSQL. These changes are taken from
Rails pull request https://github.com/rails/rails/pull/19090.

Previously this class would be given a project ID which was then used to
retrieve the corresponding Project object. However, in all cases the
Project object was already known as it was used to grab the ID to pass
to ProjectSearchResults. By just passing a Project instead we remove the
need for an extra query as well as the need for some other complexity
in this class.

This removes the need for plucking snippet IDs into memory.

Instead of plucking IDs this class now uses ActiveRecord::Relation
objects. Plucking IDs is problematic as searching for projects can lead
to a huge amount of IDs being loaded into memory only to be used as an
argument for another query (instead of just using a sub-query).

Previously this used a regular LIKE which is case-sensitive on
PostgreSQL. This ensures that for both PostgreSQL and MySQL the
searching is case-insensitive similar to searching for projects.

Similar to the changes made to Project.search the method
Project.search_by_title now also uses Arel so it can automatically use
ILIKE/LIKE instead of the lower() function.

This chance is broken up in two steps:

1. Use ILIKE on PostgreSQL and LIKE on MySQL, instead of using
   "WHERE lower(x) LIKE lower(y)" as ILIKE is significantly faster than
   using lower(). In many cases the use of lower() will force a slow
   sequence scan.

2. Instead of using 1 query that searches both projects and namespaces
   using a JOIN we're using 2 separate queries that are UNION'd
   together. Using a JOIN would force a slow sequence scan, using a
   UNION avoids this.

This method now uses Arel as Arel automatically uses ILIKE on PostgreSQL
and LIKE on MySQL, removing the need to handle this manually.

This allows the LIKE condition to use an index. Without a GIN + trigram
index LIKE queries using a wildcard at the start _won't_ use an index
and instead perform a sequence scan.

Move group activity feed to separate page for consistency with dashboard
and project pages

Fixes #14161. Part of #13480 

See merge request !3157

Fix incorrect gitlab.rb variable in CI docs

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

See merge request !3187

[ci skip]

Improved search results filter dropdown

## Current

Currently filter dropdowns on search results page can be **very** long and off the page

![Screen_Shot_2016-03-11_at_15.25.24](/uploads/3418b0a6f4f8a0a8bd2441b53502c574/Screen_Shot_2016-03-11_at_15.25.24.png)

## New

Changed over to the new dropdown

![Screen_Shot_2016-03-11_at_15.29.06](/uploads/2d3a4a9b3e50f3e0fc1748a026cd5905/Screen_Shot_2016-03-11_at_15.29.06.png)

See merge request !3183