GitLab

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>

Stop the global search form's default "action" from fighting with
dropdown items when using the keyboard to navigate the dropdown.
`e.preventDefault()` is now called on the enter key when a dropdown item
is already selected.
Signed-off-by: Rémy Coutable <remy@rymai.me>

Fixes #21800.

ExpireBuildArtifactsWorker query builds table without ordering enqueuing one job per build to cleanup

We use Sidekiq::Client.push_bulk to avoid Redis round trips

The Sortable concern has a default scope that adds ORDER BY to all
queries. EXPLAIN ANALYZE shows that this additional ORDER BY statement
causes the SQL optimizer to use the wrong index, which leads to a load
time of 2.9 s vs 0.073 ms just for the SELECT call. The minimal
change here is to re-implement find_by using where and reorder to
remove the ORDER BY clause in IssuesController#index.

Closes #23075

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

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

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

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

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

add docs and tests - add additional validation
allow move without content
updated response

  - Includes documentation and tests

== Public Projects

This finder class now _only_ returns public projects. Previously this
finder would also return private and internal projects. Including these
projects makes caching data much harder and less efficient. Meanwhile
including this data isn't very useful as very few users would be
interested in seeing projects they have access to as trending. That is,
the feature is more useful when you want to see what _other_ popular
projects there are.

== Caching

The data returned by TrendingProjectsFinder is now cached for a day
based on the number of months the data should be restricted to. The
cache is not flushed explicitly, instead it's rebuilt whenever it
expires.

== Timings

To measure the impact I changed the finder code to use the last 24
months instead of the last month. I then executed and measured 10
requests to the explore page. On the current "master" branch (commit
88fa5916) this would take an average of
2.43 seconds. Using the changes of this commit this was reduced to
around 1.7 seconds.

Fixes gitlab-org/gitlab-ce#22164

This refactors Gitlab::Identifier so it uses fewer queries and is
actually tested. Queries are reduced by caching the output as well as
using 1 query (instead of 2) to find a user using an SSH key.

Projects that are destroyed are put in the pending_delete state.
The ProjectDestroyWorker checks whether the current user has
access, but since the ProjectFeature class uses the default scope
of the Project, it will not be able to find the right project.

This was a regression in 8.12 that caused the following stack trace:

```
NoMethodError: undefined method `team' for nil:NilClass
  from app/models/project_feature.rb:62:in `get_permission'
  from app/models/project_feature.rb:34:in `feature_available?'
  from app/models/project.rb:21:in `feature_available?'
  from app/policies/project_policy.rb:170:in `disabled_features!'
  from app/policies/project_policy.rb:29:in `rules'
  from app/policies/base_policy.rb:82:in `block in abilities'
  from app/policies/base_policy.rb:113:in `collect_rules'
  from app/policies/base_policy.rb:82:in `abilities'
  from app/policies/base_policy.rb:50:in `abilities'
  from app/models/ability.rb:64:in `uncached_allowed'
  from app/models/ability.rb:58:in `allowed'
  from app/models/ability.rb:49:in `allowed?'
  from app/services/base_service.rb:11:in `can?'
  from lib/gitlab/metrics/instrumentation.rb:155:in `block in can?'
  from lib/gitlab/metrics/method_call.rb:23:in `measure'
  from lib/gitlab/metrics/instrumentation.rb:155:in `can?'
  from app/services/projects/destroy_service.rb:18:in `execute'
```

Closes #22948

Per GitLab.com's performance metrics this method could take up to 5
seconds of wall time to complete, while only taking 1-2 milliseconds of
CPU time. Removing the Redis lease in favour of conditional updates
allows us to work around this.

A slight drawback is that this allows for multiple threads/processes to
try and update the same row. However, only a single thread/process will
ever win since the UPDATE query uses a WHERE condition to only update
rows that were not updated in the last hour.

Fixes gitlab-org/gitlab-ce#22473