If you are running another sidekiq instance on your server, e.g. GitLab
CI, the check script would parse the output of `ps aux` searching for
`sidekiq` and returning success, although the GitLab sidekiq may not be
running.

Now the `ps` call will only print the processes run by the GitLab user.

* GitLab Shell 1.7.1 is required
* Global projects are not supported (refs #5152)

Use gitlab-shell authorized_keys truncation. Fix issue with authorized_keys stored in different location

When the file that pointed git bin_path in gitlab.yml dose'nt exist,
bundle rake gitlab:app:check would be aborted.

refs #4205

Signed-off-by: Axilleas Pipinellis <axilleas@archlinux.gr>

These fixes will allow a restore of gitlab when the backups and
repositories directories are in non-standard locations (ie sub-dirs
of gitlabhq).  Also allows the restore to be run from script
overriding the need of a user to confirm the rebuild of the
authorized_keys file.

Expand the import glob to include `**/*.git` to find projects in groups
as well as top level projects.  Check for existing group, and create
group if needed.  Set namespace_id for imported projects.

e.g.: the sidekiq in my Debian box is v2.11.1

It returns "yes" if required version is "1.7.10" and current version is "1.6.10",
because the patch version of current version equals to that of required version.

Checking is "yes" only if git version equals "1.7.10" exactly.

If the backup directory is not sub the gitlab install directory,
then the git rev-parse call will fail.

Checking the redis version will warn users that
are using an old version to update. Included
reference to the troubleshooting guide.