This caches the output of Repository#exists? in Redis while making sure
it's flushed properly when creating new repositories, deleting them,
etc.

For the ProjectWiki tests to work I had to make ProjectWiki#create_repo!
public as testing private methods in RSpec is a bit of a pain.

The queries that are UNION'd together don't need any eager loading
(since we really only use the resulting SQL instead of having
ActiveRecord actually run the queries). By dropping any eager loaded
associations queries such as the following work instead of producing a
SQL error:

    Project.all.includes(:namespace).search('foo')

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.

Prevent Groups to have smaller visibility than projects
Add default_group_visibility_level to configuration
Code improvements

This ensures that if a project is later re-created using the old path it
doesn't end up re-using the old cache. This also ensures we don't keep
the cache around until its expired by Redis itself.

Fixes gitlab-org/gitlab-ce#13790

This is needed to support Huboard and a generally useful value.

This method can be used to filter projects to those visible to a given
user.

- Enable CI by default for all new projects

This changes the query to use a COUNT nested in an INNER JOIN, instead
of a COUNT plus a GROUP BY. There are two reasons for this:

1. Using a COUNT in an INNER JOIN can be quite a bit faster.
2. The use of a GROUP BY means that method calls such as "any?"
   (and everything else that calls "count") operate on a Hash that
   counts the amount of notes on a per project basis, instead of just
   counting the total amount of projects.

The query has been moved into Project.trending as its logic is simple
enough. As a result of this testing the TrendingProjectsFinder class
simply involves testing if the right methods are called, removing the
need for setting up database records.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

This reverts commit 5daf44b7, reversing
changes made to 2f706fbd.

This reverts commit 957e849f, reversing
changes made to 6b9dbe9f.
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>