Including shared library causes extra builds to be queued on MR edit

## Issue
Including a shared Library, causes any edits to an MR (such as adding a label) to create another build, even when builds for the latest commit have already started.

### Context
- **Gitlab plugin version**: 1.4.2
- **Gitlab version**: 8.13.1-ee 3f76553
- **Jenkins version**: 2.32.3
- **Job type**: Pipeline

### Logs & Traces
[Jenkins GItlab Plugin.txt](https://github.com/jenkinsci/gitlab-plugin/files/1056737/Jenkins.GItlab.Plugin.txt)

### Problem description
Using the simple pipeline groovy script below, when the @Library reference is excluded, an MR is created and built as expected. Editing the MR to change the labels does not start a new build. You can see this behaviour in the fix/2build2 branch in the logs.

When the @Library call is included, an MR is created and a build is started as expected. Then before the original build is finished, if the labels are updated on the MR, a new build is incorrectly queued.
It seems similar to Issue #523, except I am on the Pipeline Multibranch plugin v 2.12 and not using Multibranch Pipelines.

```
//Pipeline groovy
// in the log, branch fix/2build2 is the one without the library include; the fix/2build4 branch is the one with the @Library
//@Library('jenkins-sharedlibs')

graphitePrefix = ""
cookbookName = "pipeline_test"
gitUrl = ""
credentialsId = ""
productionBranch = "master"
maxParallel = 4
node('master') {
//Create a new workspace for gem jobs that have spaces replaced with underscores.
//Spaces seem to break some jobs
ws(env.JOB_NAME.replaceAll(' ','_')) {
deleteDir()
checkout([$class: 'GitSCM', branches: [[name: sourceBranch()]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: credentialsId, url: gitUrl]]])
sleep(120)
}
}
def sourceBranch() {
if (env.gitlabSourceBranch != null)
return env.gitlabSourceBranch
return 'master'
}
```