"Maintainer" will be freed to be used for #42751

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

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

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

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

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

This index is added on `(target_project_id, iid)` and has a `WHERE state
= 'opened'` condition. Using this index we can drastically improve the
performance of the query used to count the total number of merge
requests in a group. Without this index the query would eventually
perform the following:

    ->  Index Scan using index_merge_requests_on_target_project_id_and_iid on merge_requests  (cost=0.43..4.89 rows=7 width=4) (actual time=0.058..0.353 rows=6 loops=228)
          Index Cond: (target_project_id = projects.id)
          Filter: ((state)::text = 'opened'::text)
          Rows Removed by Filter: 141
          Buffers: shared hit=34351 dirtied=1

Out of the ~180 milliseconds the entire query would take, around 170
milliseconds was spent in just this segment. With the index in place,
the above segment is turned into the following:

    ->  Index Only Scan using yorick_test on merge_requests  (cost=0.42..0.55 rows=7 width=4) (actual time=0.004..0.010 rows=6 loops=228)
          Index Cond: (target_project_id = projects.id)
          Heap Fetches: 419
          Buffers: shared hit=1381

The index also reduces the total query time to roughly 10 milliseconds.

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

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

We request Gitaly in a N+1 manner to build discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
With this change we solve this problem and simplify a lot fetching this piece of info.

Closes #46530.

Closes #32258.

This commit has two migrations:

1. The first prunes duplicate rows in the project_features table and leaves
   the row with the highest ID.  Since the behavior was indeterministic before
   and depended on which row the database decided to use, this change at least
   makes the permissions consistent. For example, in some cases, the Wiki may
   have been disabled but enabled in another entry.

2. The second adds a non-null constraint on the project_features.project_id
   column.

Closes #37882

Fixes a significant part of gitlab-com/migration#408.

We found that we were overcounting Wikis because of these duplicates.
On GitLab.com, there are 56 rows with duplicate entries by project_id, and 16,661 rows with NULL project_id values.

We use this to filter runner and will use this increasingly in future
instead of is_shared so it should be indexed

This will act as a cache, otherwise we would need to load the
`term_agreements` for a user on each request.

Using this field the result we're interested in is loaded when the
current user is loaded, without causing an extra query.

That way we can link a users acceptance of terms directly to a terms record.

Add a flag to applications settings to enforce users to accept terms
before using the GitLab instance