Allow user to be blocked and activated via the API

When authenticating against LDAP if a user has been disabled in LDAP they can no longer log on to the website or commit over http(s) but will be able to commit using any ssh keys.  This functionality allows us to look for users in GitLab that no longer exist in LDAP and disable then in GitLab.

Closes Feedback item: [Add administrative API call to block users](http://feedback.gitlab.com/forums/176466-general/suggestions/4098632-add-administrative-api-call-to-block-users)

See merge request !587

Changed the reference from gitlab cloud to gitlab.com because it was outdated.

This one confused me a bit because i was searching for gitlab cloud and the first thing i saw: "It's gone and now it's gitlab.com"
So to prevent anyone other than me from being a bit puzzled this little change should help

See merge request !929

Fix redirection to home page URL for unauthorized users

Redirection to the home page URL was broken by changing the target for
`root_url` from `DashboardController` to `RootController` in
94d3c143. This regression was introduced
in the 7.12.0 release.

Fixes #1916.

See merge request !928

Redirection to the home page URL was broken by changing the target for
`root_url` from `DashboardController` to `RootController` in
94d3c143. This regression was introduced
in the 7.12.0 release.

Fixes #1916.

Change RC/final package release timing

Creating the packages one day before the release feels strange, especially in a month like this (June 2015) where the release is on a Monday.

I think it is better to have one more RC.

See merge request !1873

Add support for unlocking users in admin settings

### What does this MR do?

This MR gives the ability to unlock a user from the Admin panel.

### Why was this MR needed?

If a user fails to login a certain number of times, Devise locks the user out for a certain amount of time (e.g. 10 minutes). There is no way for an admin to unlock a user if this happens (aside from editing the `locked_at` field entirely).

### Screenshots

#### Admin index page

![image](https://gitlab.com/gitlab-org/gitlab-ce/uploads/14c661d1d1f026770997b19af714c514/image.png)

#### Admin edit user page

![image](https://gitlab.com/gitlab-org/gitlab-ce/uploads/0c6f795757e5f03eeb923d818b7d6a96/image.png)

### What are the relevant issue numbers?

This replaces !288.

Closes https://github.com/gitlabhq/gitlabhq/issues/9381

See merge request !922

'created_at DESC' is performed twice

If you are already sorting in descending order in the created_at, it is run twice when you run the .recent.

It has passed in the string 'created_at DESC'.
Ruby on Rails is directly given to the SQL.
It is a slow query in MySQL.

See merge request !825

If you are already sorting in descending order in the created_at,
it is run twice when you run the .recent.
It has passed in the string 'created_at DESC'.
Ruby on Rails is directly given to the SQL.
It is a slow query in MySQL.

Closes https://github.com/gitlabhq/gitlabhq/issues/9381

Correctly show anonymous authorized applications under Profile > Applications.

Fixes #1907.

Access tokens that were created using the ["Resource Owner Password Credentials" flow](http://doc.gitlab.com/ce/api/oauth2.html#resource-owner-password-credentials) by the user entering their username and password don't have a connected application, so the Profile > Applications page used to crash. These tokens are now rendered as "Anonymous" and can be revoked.

![Screen_Shot_2015-07-02_at_11.53.55](https://gitlab.com/gitlab-org/gitlab-ce/uploads/0fb044ce1fbf5d5e2825c3abee7763ee/Screen_Shot_2015-07-02_at_11.53.55.png)

See merge request !924

Add Troubleshooting section to SAML doc.

In response to #1898. We'll properly fix it in another MR.

See merge request !917

Remove link leading to a 404 error in Deploy Keys page

### What does this MR do?

This MR removes a link that would lead an admin to believe he/she could edit a deploy key, but clicking on this link would lead to a 404.

### Screenshot

![image](https://gitlab.com/stanhu/gitlab-ce/uploads/b36cd76287d6389a09f9e0e49c1b6751/image.png)

### What are the relevant issue numbers?

Closes #1866

See merge request !923

New document about creating a project

Added new document to GitLab Basics about creating a project

See merge request !1885

Gem updates for security issues

- sprockets (rails dependency, but we need to specify a version to pull
  in fixes)
- sass-rails (no security issues, but required an update to meet new
  sprockets version requirement)
- rest-client (coveralls dependency)

See merge request !915

Closes #1866

Fix changelog for !767 and !794

These changes did not make it into the 7.12.0 release. The entry for
!794 is already correctly listed for 7.12.1 so it has been removed.

See merge request !920

commit hashes are monospaced

Use a monospaced font for GFM commit and commit range references

See merge request !914

These changes did not make it into the 7.12.0 release. The entry for
!794 is already correctly listed for 7.12.1 so it has been removed.

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

Add an expect call to prevent random Spinach failure

This should help prevent getting the error:

```
Unable to find field "merge_request_title
```

This was happening probably because it takes some time after the "Compare branches" button is hit before the "New merge request" page showed up.

See merge request !882

Refactor can_be_merged logic for merge request

Some refactoring after !918

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

See merge request !919

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

Merge branches inside one repository using rugged instead of satellites
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

cc @rspeicher @DouweM

See merge request !918

Extract the longest-matching ref from a commit path when multiple matches occur

### What does this MR do?

This MR extracts the longest-matching ref from a commit path. In cases when there are multiple refs that prefix the path, the ref name is ambiguous. Using the heuristic that the longest-matching ref seems like a sensible default.

### Why was this MR needed?

Suppose there is a branch named `release/app` and a tag named `release/app/v1.0.0`. Suppose `README.md` exists in the root directory.

Let's suppose the path passed in is `release/app/v1.0.0/README.md`. There are two possible ways to interpret the ref and path:

1. ref = `release/app`, path = `v1.0.0/README.md`
2. ref = `release/app/v1.0.0`, path = `README.md`

The crux of the issue is that there is ambiguity which one is correct; both could be real possibilities. In the current implementation of `extract_ref`, GitLab gets confused and tries neither: it uses ref = `release` and path = `app/v1.0.0/README.md`. Since the file does not exist, it returns 404.

### What are the relevant issue numbers?

Closes #1839

See merge request !859

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

Closes #1839

Fix GitLab CI forking

I created MR here because gitlab.com is unreachable.

See merge request !1884