Temporary branch for external MRs

[Jellby]

This is at least an initial solution for #111. When a MR is created from a fork, if the temp_branch option is given, Marge will create a temporary branch with that name in the target project and check the CI result of this branch instead of the source project. This requires overriding the "only merge if CI passed" and "wait until CI succeeds" options of GitLab. The temporary branch is removed after a successful merge

[aschmolck]

Being able to deal with external MRs in cases where you don't control the forks (e.g. if you're hosting an open source repo on gitlab.com) seems quite desirable, and I think creating an integration branch of some sort in the target repo is the way to go, given that MR CI in gitlab is basically screwed up completely ATM.

However, the way this is currently implemented is too brittle: marge remains stateless, and you change global project settings, which won't be restored if marge crashes for some reason. This could lead to some quite nasty suprises. I'll need to think a bit about what a good way of dealing with this is; the changing of project settings is nasty and if there is no other way to to do it, it definitely has to be made as robust as possible.

[Jellby]

I agree changing project settings is not very nice. It could be argued (and I did) that the "Only allow merge requests to be merged if the pipeline succeeds" is quite useless for external MRs. I tried to implement it as robust as possible, but I'd be happy to hear other suggestions.

I don't quite understand the problem with "statelessness". Note that marge is not adding any new commits to the target project (at least not with the merge strategy... I think she won't with rebase either), she's just changing the tip of the temporary branch.

[aschmolck]

The problem with statelessness is that this might never run:

        finally:
            if reset:
                project.set_only_allow_merge_if_pipeline_succeeds(True, self._api)

To make it robust, you'd need to save the fact that you want to restore the setting persistently (e.g. in a database or a file) before you actually change it. This would make marge-bot stateful.

I think a better solution is doing what we do for batch merge requests though and just "manually" merge the branch.

[Jellby]

Is it better like this? No changes to project settings (only to protect/unprotect the temporary branch, but the temporary branch is supposed to be disposable).

(Note that I think this would fix #122, see change in marge/job.py 199->204)