And the link to the last page cannot be `page=0`.

Add specs that check the 'Link' header for the inclusion of:

 - rel="first"
 - rel="last"
 - rel="prev"
 - rel="next"

Fixes gitlab-org/gitlab-ce#36618

Related to gitlab-com/infrastructure#2532

Previously the user could not delete his own account unless signup was
enabled in the global settings. This was due to the fact that deleting
the user would also delete the issues and other items associated to him.
Deleting an user does not destroy essential data anymore, for this
reason we removed the `signup_enabled?` check.

Backports EE mirror stuck handling feature (https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2628) to CE

`migrate!` helper triggers a migration that is under the test, so we
need to revert it before each subsequent example. This means that we
need to place it in `before(:each, :migration)` hook.

We still want to migrate everything up *after* each *context*, so in
otherwords we need to place migrate up helper in `before(:context,
:migration)`.

The params were not getting a value other than `project_templates:"on"`
so the backend wasn't sure what template to use.

Fixes gitlab-org/gitlab-ce#36492

This allows testing every storage attempt after a failure. Which could
be useful for tests

The `Rails` object was not always available in all tasks that require
Redis access, such as `mail_room`, so the constant pointing to the
configuration path was never defined, but we still attempted to access
it in `config_file_name`, resulting in a `NameError` exception.

Further, there was no benefit to defining these paths in a constant to
begin with -- they're only accessed in one place, and it was within the
class where they were being defined. We can just provide them at
run-time instead.

Further _still_, we were calling `File.expand_path` on the absolute path
returned by `Rails.root.join`, which was rather pointless.

The dispatcher was trying to create a new instance of a class that is loaded in a file after main.js which would cause the filtered search to not work on issues. This would only happen on the first load when the JS is not cached. If the JS is cached, then everything will be fine.

Related to !13108. Mostly this is just running the rake task and
changing the task a bit to catch cases like the project already existing
or so. The rake task moves archives to the vendor/project_template
directory, which are checked in too.

In some cases we pass an Array to this method which would previously
fail since Array does not respond to "limit_value".

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/3646