Up until version 2.0.3 redis-rack included a "rake" binary that would
overwrite/hijack the one provided by Rake itself. Unfortunately the
binary provided by redis-rack would produce errors in many cases. See
https://github.com/redis-store/redis-rack/pull/34 for more info.

When a project uses fast-forward merging strategy user has
to rebase MRs to target branch before it can be merged.
Now user can do rebase in UI by clicking 'Rebase' button
instead of doing rebase locally.

This feature was already present in EE, this is only backport
of the feature to CE. Couple of changes:
* removed rebase license check
* renamed migration (changed timestamp)

Closes #40301

`Gitlab::LDAP::Person` did not respect the LDAP attributes username
configuration and would simply return the uid value. There are
cases where users would like to specify a different username field
to allow more friendly GitLab usernames. For example, it's common
in AD to have sAMAccountName be an employee ID like `A12345` while
the local part of the email address is more human-friendly.

Old merge requests can have diffs without corresponding blobs. (This also may be
possible for commit diffs in corrupt repositories.)

We can't use the `&.` operator on the blobs, because the blob objects are never
nil, but `BatchLoader` instances that delegate to `Blob`. We can't use
`Object#try`, because `Blob` doesn't inherit from `Object`.

`BatchLoader` provides a `__sync` method that returns the delegated object, but
using `itself` also works because it's forwarded, and will work for
non-`BatchLoader` instances too. So the simplest solution is to just use that
with the `&.` operator.

This ensures that the "author" association of an event's "target"
association is eager loaded whenever the "target" association defines an
"author" association. This in turn solves the N+1 query problem we first
tried to solve in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15788 but caused
problems when displaying milestones as those don't define an "author"
association.

The approach in this commit does mean that the authors are _always_
eager loaded since this takes place in the "belongs_to" block. This
however shouldn't pose too much of a problem, and as far as I can tell
there's no real way around this unfortunately.

This commit extracts `kubectl`, `helm` and `codeclimate` versions as CI
variables.

`kubectl` changes from latest stable version to `1.8.6`, the other two are just
extracted in order to be easily updated; now we can also test tool upgrades
overriding CI secret variables.

If the payload cannot be created for some reason, we could be left with a nil
push event payload, which causes Error 500s when viewing the dashboard. Guard
against this error and log when it happens.

Avoids problems seen in #38823

Both the post-deploy and background migration.

- Removed disable button from /profile/account
- Added disable button to /profile/two_factor_auth
- Changed 2FA breadcrumb from 'User Settings > Account > Account' to 'User Settings > Account > Two-Factor Authentication'

In a previous attempt (rolled back in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16021) we tried
to migrate `issues.closed_at` from timestamp to timestamptz using a
regular migration. This has a bad impact on GitLab.com and as such was
rolled back.

This commit re-implements the original migrations using generic
background migrations, allowing us to still migrate the data in a single
release but without a negative impact on availability.

To ensure the database schema is up to date the background migrations
are performed inline in development and test environments. We also make
sure to not migrate that that doesn't need migrating in the first place
or has already been migrated.

The previous implementation iterated across the entire patch set
to determine the number of lines added, deleted, and changed. Rugged
has a native method `Rugged::Diff#stat` that does this already,
which appears to be a little faster and require less RAM than doing
this ourselves.

Improves performance in #41524

In some cases is prefered to manually create a ProjectWiki over using
Project#wiki. This is because Project#wiki always uses the #owner (which
is a User sometimes) as the
author of the wiki changes but sometimes the owner is a Group and it
doesn't respond to #username

[ci skip]

When searching for issues, an additional subquery
is added which filters only issues in a project. If global context is
used (no project is specified) this query filters all projects user has
access to.

In that case we can skip this filter because filtering only projects
user has access to is added anyway.

The filter is used only if a custom project context is specified

Related to #40540

Closes #40274

This change is required because otherwise if a user is created with a
value for `projects_limit` that matches the DB default, it gets
overwritten by `current_application_settings.default_projects_limit`. By
removing the default we once again can allow a user to be created with a
limit of 10 projects without the risk that it'll change to 10000

When editing an issue, use the PUT method instead of POST to avoid
a 404 after solving the reCAPTCHA.

Closes #41445