Allow 'rebase and merge' when FF/Rebase is required and MR is from a fork
In the future, if a MR comes from a fork and FF merge/rebase is required, only the fork members can initiate a rebase. The reasons for this are the principle of least surprise as far as permissions is concerned. See gitlab-org/gitlab-ee#85 and gitlab-org/gitlab-ee!111.
I thought of this after reading the point in #8938 (moved):
Support linear histories in the big green merge button. The project maintainer should be able to specify whether merge commits should be created, or the change should be rebased on top of master.
I understand why we should not allow an upstream member to rebase code on a user's fork branch. What if we added a 'Rebase and Merge' feature that would allow an upstream member to simultaneously rebase and merge. This rebase operation would only take place in the copied ref (We do that now for MR, right?). If the intent is to rebase and merge immediately there is no concern about having the branch from the fork be up to date. It's probably just to be deleted anyway.
cc/ @JobV