The status is shown for
- The author of a commit when viewing a commit
- Notes on a commit (regular/diff)
- The user that triggered a pipeline when viewing a pipeline
- The author of a merge request when viewing a merge request
- The author of notes on a merge request (regular/diff)
- The author of an issue when viewing an issue
- The author of notes on an issue
- The author of a snippet when viewing a snippet
- The author of notes on a snippet
- A user's profile page
- The list of members of a group/user

* adds basic discussions API for issues and snippets
* reorganizes notes specs (so same tests can be used for all noteable types - issues, MRs, snippets)

Merge branch 'security-10-4-25223-snippets-finder-doesnt-obey-feature-visibility' into 'security-10-4'

[Port for security-10-4]: Makes SnippetFinder ensure feature visibility

The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.

To fix this:

1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
   `Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
   like that in several places.
3. Change the initializers to use that new form.

This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).

Douwe Maan authored 7 years ago and Bob Van Landuyt :neckbeard: committed 7 years ago

Refactor snippets finder & dont return internal snippets for external users

See merge request !2094

Add `visibility` & `visibility=` methods to the
`Gitlab::VisibilityLevel` module so the `visibility_level` can be
get/set with a string value.

Apply the same spam checks to public snippets (either personal snippets
that are public, or public snippets on public projects) as to issues on
public projects.

When a snippet is submitted, but there's an error, we didn't keep the
visibility level. As the default is private, this means that submitting
a public snippet that failed would then fall back to being a private
snippet.

Also added relevant specs and refactored to_references in a bunch of places to be more consistent.

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

This commit adds a number of _html columns and, with the exception of Note,
starts updating them whenever the content of their partner fields changes.

Note has a collision with the note_html attr_accessor; that will be fixed later

A background worker for clearing these cache columns is also introduced - use
`rake cache:clear` to set it off. You can clear the database or Redis caches
separately by running `rake cache:clear:db` or `rake cache:clear:redis`,
respectively.

`notes_with_associations` are used for `participant` declarations, but `Participable`
only really cares about the target entity project, and not the participants
projects.

`notes_with_associations` are also used in `Commit::has_been_reverted?` which
employs the reference extractor of the commit, so no references to the notes
projects are made there (`Mentionable::all_references` cares only about the
`author` and other `attr_mentionable`). A paralel situation occurs on
`Issue::referenced_merge_requests`.

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

There are several changes to this module:

1. The use of an explicit stack in Participable#participants
2. Proc behaviour has been changed
3. Batch permissions checking

== Explicit Stack

Participable#participants no longer uses recursion to process "self" and
all child objects, instead it uses an Array and processes objects in
breadth-first order. This allows us to for example create a single
Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
a ReferenceExtractor removes the need for running potentially many SQL
queries every time a Proc is called on a new object.

== Proc Behaviour Changed

Previously a Proc in Participable was expected to return an Array of
User instances. This has been changed and instead it's now expected that
a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
value of the Proc is ignored.

== Permissions Checking

The method Participable#participants uses
Ability.users_that_can_read_project to check if the returned users have
access to the project of "self" _without_ running multiple SQL queries
for every user.

In 8278b763 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.

Fixes: #17382

These methods are called quite often in loops so by memoizing their
output we can reduce timings a bit.

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

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.