Incorrect SHA checked out on completed merge request

### Version report

Jenkins and plugins versions report:

```
Jenkins: 2.289.1
OS: Linux - 3.10.0-957.21.3.el7.x86_64
gitlab-plugin:1.5.20
```

- What Operating System are you using (both controller, and any agents involved in the problem)?

```
Linux RedHat RHEL7
```

- Gitlab version: 13.12.1

### Reproduction steps

- Create Jenkins job to be triggered only by accepted merge requests
- Including the following in the pipeline script:
```
checkout ([
$class: 'GitSCM',
branches: [[name: "origin/${env.gitlabTargetBranch}"]],
extensions: [
[$class: 'PruneStaleBranch'],
[$class: 'CleanCheckout'],
[$class: 'LocalBranch', localBranch: env.gitlabTargetBranch]
],
userRemoteConfigs: scm.userRemoteConfigs
])
```
- Create and merge a merge request (for example, Develop -> Master)

### Results

Expected result:

The latest commit of the target branch is checked out into a local branch with a matching name

Actual result:

The latest commit of the *source* branch is checked out into a local branch that matches the *target* branch name

### Diagnosis / workaround:
This would appear to be due to the way the webhook from gitlab is handled - the "last_commit" details in the hook are actually those of the head of the branch being merged in. The resulting merge commit sha is actually sent through in the object_attributes.merge_commit_sha field, but it is "last commit" that is checked out and as such the local branch ends up one commit behind the the remote. This causes particular problems when trying to run maven releases - these fail with an error.

The workaround is to add the following as a secondary step after the checkout:
```
sh "git branch --set-upstream-to=origin/${env.gitlabTargetBranch} ${env.gitlabTargetBranch} && git pull"
```
However this feels like a hack - shouldn't a completed merge request check out the full result of the merge?