When signing in with SSO, if the default behaviour of gitlab is to block SSO user, the only message the people will get is 'Your account was blocked'

They should get the idea this might be only temporary and not because of a technical problem

* Move is_assigned? and is_being_xx? methods to IssueCommonality

  This is behavior merge requests have in common with issues. Moved
  methods to IssueCommonality role. Put specs directly into
  merge_request_spec because setup differs for issues and MRs
  specifically in the "closed" factory to use.

* Add MergeRequestObserver. Parallels IssueObserver in almost every way.

  Ripe for refactoring.

* Rename MailerObserver to NoteObserver

  With merge request observing moved out of MailerObserver, all that
  was left was Note logic. Renamed to NoteObserver, added tests and
  updated application config for new observer names. Refactored
  NoteObserver to use the note's author and not rely on current_user.

* Set current_user for MergeRequestObserver

  IssueObserver and MergeRequestObserver are the only observers that
  need a reference to the current_user that they cannot look up on
  the objects they are observing.

Because of the way ExtractPaths works, `params[:format]` wouldn't
necessarily be available at the time this filter was running, and so it
would erroneously redirect to `new_user_session_path`

Handles stuff that's shared across admin controllers.

That was the only place it was used.

As a last resort it was calling a method that didn't exist. Woops!

Replaces two calls that this method simplifies

Merge branch 'master' into non-interactive-aws-install

Conflicts:
	doc/installation.md

Fix merge mess in installation.md

Didn't bother with files in db/, config/, or features/