merge_error field for MR not being cleared
<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label:
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
We create and accept a lot of MRs via API calls. In some cases merging an MR via a call to
```
PUT /projects/:id/merge_requests/:merge_request_iid/merge
```
with `merge_when_pipeline_succeeds` set to `True` results in 200 code but `merge_error` field is set to `Merge failed: Merge request is not mergeable. Please try again.` and MR is not merged. We suspect this might be the same issue as described here: https://gitlab.com/gitlab-org/gitlab/issues/27596 but are currently unable to tell in what corner cases it appears. When creating a workaround in our code, we assumed we could rely on `merge_error` field to check if MR became mergeable again. However, this is not the case. Once this field gets filled, its value is never cleared even though MR can be merged or even after the merge has successfully ended.
### Steps to reproduce
1. Create MR against a project via API call
2. Try to approve it via API call straight away with `merge_when_pipeline_succeeds` set to `True`
3. Encounter this problem: https://gitlab.com/gitlab-org/gitlab/issues/27596 (response is 200, but `merge_error` set to `Merge failed: Merge request is not mergeable. Please try again.`
4. Wait some time and merge MR via UI or another API call
5. `merge_error` field stays filled
### What is the current *bug* behaviour?
`merge_error` field stays filled with `Merge failed: Merge request is not mergeable. Please try again.
` even though MR is mergeable or even already merged in. The error message is shown on the UI.
### What is the expected *correct* behaviour?
`merge_error` field should be clear if MR can be merged or was already merged.
### Relevant logs and/or screenshots


#### Our Gitlab instance
We're seeing this in GitLab Enterprise Edition 12.2.5-ee.
issue