Reintroduce minimum gitlab system requirement

As per https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/1249#note_29946

See merge request !1286

Improve issuable form links UX

> The create new label / milestone links should open in a new window / popup to avoid losing information already filled in for a new issue.

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

See merge request !1291

Improve search ux

When I use search from merge requests page I usually want to see merge requests results. If I do search from wiki pages -> I want to see wiki results first.

With this patch search scope is set to issues if you are on issues controller and same for merge requests and wikis

See merge request !1290

Fix safari ui bug

See merge request !1289

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>

Improve MR reloading

## Theory

Every time you pushed to master it updates merge requests that has master
as target branch. So if you have 50 open merge requests point to master
it will reload all of them every time you push a single commit to
master. The funny thing is that after reloading diff of most merge
requests looks the same.

After this patch we update diff only if we push commit to master that
includes in MR commits list.

For example we have next repository:

    feature: A - B - C
    master: A

We create merge request with code from feature to master.

    MR: B - C

If we push to master commit D - MR will not be reloaded. So picture will
look next:

    feature: A - B - C
    master: A - D
    MR: B - C

And if we push to master commit B - MR will be reloaded. So picture will
look next:

    feature: A - B - C
    master: A - B
    MR: C

## Benchmark

For project with 45 open merge requests to master

Before

```
Benchmark post-receive | Cache and size:   0.060000   0.040000   0.100000 (  0.379720)
Benchmark post-receive | Push commits selection:   0.130000   0.020000   0.150000 (  0.149299)
Benchmark post-receive | Update merge requests:   9.180000   2.030000  11.210000 ( 11.971747)
Benchmark post-receive | Process commit messages:   0.140000   0.010000   0.150000 (  0.168810)
Benchmark post-receive | Push data:   0.020000   0.000000   0.020000 (  0.016363)
Benchmark post-receive | Push event and services:   0.030000   0.000000   0.030000 (  0.088062)
```

After

```
Benchmark post-receive | Cache and size:   0.070000   0.030000   0.100000 (  0.106676)
Benchmark post-receive | Push commits selection:   0.130000   0.020000   0.150000 (  0.143081)
Benchmark post-receive | Update merge requests:   0.660000   0.210000   0.870000 (  0.892663)
Benchmark post-receive | Process commit messages:   0.030000   0.000000   0.030000 (  0.029263)
Benchmark post-receive | Push data:   0.020000   0.000000   0.020000 (  0.018479)
Benchmark post-receive | Push event and services:   0.030000   0.000000   0.030000 (  0.038230)
```
- - -

## References

Discussion in gitlab/gitlabhq#1796

See merge request !1288

Update libv8

For some reason I could no longer install the previous version of libv8 on my development machine; this version bump fixes that.

I do not know if/how this change affects production environments.

See merge request !1287

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

Every time you pushed to master it updates merge requests that has master
as target branch. So if you have 50 open merge requests point to master
it will reload all of them every time you push a single commit to
master. The funny thing is that after reloading diff of most merge
requests looks the same.

After this patch we update diff only if we push commit to master that
includes in MR commits list.

For example we have next repository:

feature: A - B - C
master: A

We create merge requests #1 with code from feature to master.

MR #1: B - C

If we push to master commit D - MR will not be reloaded. So picture will
look next:

feature: A - B - C
master: A - D
MR #1: B - C

And if we push to master commit B - MR will be reloaded. So picture will
look next:

feature: A - B - C
master: A - B
MR #1: C
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

This selfish change fixes 'bundle install' on my (OS X) development
machine.

This reverts commit 5cf6d594.

Improve mobile UI pt2

Next UI elements were improved for mobile view

* comments
* comment form
* issues navigation
* removed duplicate MR sidebar btn
* tabs

Desktop improvements:

* increase comment author username font size
* dark colour for comment author name

Related to #1493

See merge request !1285

Disable Sidekiq arguments logging by default

Some of the arguments passed to Sidekiq jobs are secret. With this
change we avoid logging those secrets, by turning off 'argument
logging' altogether.

See merge request !1282

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

Conflicts:
	CHANGELOG

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>

Change twitter handle from gitlabhq -> gitlab

Username in comments

Its hard to mention person in comment if you don't know his username.
This patch show person username right after his name in comment row

See merge request !1281

HipChat custom server support

add preliminary 7.6 upgrade guide

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

Fix internal api

Fixes #1787

See merge request !1280

Remove unused password argument

We no longer put a (random) password in the 'new user' email, so no need to pass it around in the code.

See merge request !1279

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

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

We were still passing a 'password' argument around, but it is not used
anywhere because we send a password reset link in the welcome email
nowadays.

Improve security release documentation

I think the MailChimp step is not needed anymore because we automated it.

See merge request !1271

Properly fix wiki restore

My previous patch didn't fix the restore issue (!247).

ProjectWiki.new() creates a new wiki git repository, so any tries to bare clone a bundle fail. With this patch we remove the newly created wiki.git before restoring from the backup bundle.

\cc @jacobvosmaer @dzaporozhets are you ok with this solution/hack?

Relevant issues: #845

See merge request !248

ProjectWiki.new() creates a new wiki git repository, so any tries
to bare clone a bundle fail. With this patch we remove the newly
created wiki.git before restoring from the backup bundle.

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

Conflicts:
	CONTRIBUTING.md

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