Allow merge when no pipeline success

What does this MR do?

• Use BE mergeable? to determine whether we can truly merge instead of trying to figure it out on the FE.

GitLab CI pipeline

Pipeline Status	Only allow merge requests to be merged if the pipeline succeeds	Before	After https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14200	After
No CI	true
No CI w/ conflicts	true
'running'	true
'failed'	true
'success'	true
'skipped'	true
No CI	false
No CI w/ conflicts	false
'running'	false
'failed'	false
'success'	false
'skipped'	false

External integration/service

Pipeline Status	Only allow merge requests to be merged if the pipeline succeeds	Before	After https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14200	After
'failed'	true
'canceled'	true
'running'	true
'pending'	true
'success'	true
'success_with_warnings'	true
'skipped'	true
'not_found'	true
---	---	---
'failed'	false
'canceled'	false
'running'	false
'pending'	false
'success'	false
'success_with_warnings'	false
'skipped'	false
'not_found'	false

Are there points in the code the reviewer needs to double check?

• Should we rename and possibly combine the canBeMerged(checks strictly whether commits merge cleanly into repo, no CI, etc) and canMerge(used for conflict checks) in the MR widget store?
  • Is it okay if we push to another ~"technical debt" MR to keep this regression fix clean?

Why was this MR needed?

• Previously, using only_allow_merge_if_pipeline_succeeds=true with no .gitlab-ci.yml (which means no pipeline) wouldn't allow you to merge. This was introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13977

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Tests added for this feature/bug
• Review
  • Has been reviewed by UX
  • Has been reviewed by Frontend
  • Has been reviewed by Backend
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together

What are the relevant issue numbers?

Closes #38389 (closed)