`CI_COMMIT_REF_NAME` points to a different ref than `CI_COMMIT_SHA`

In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9622 we introduced running pipelines on the refs/merge-requests/[iid]/merge ref instead of the tip of the source branch.

This meant that the CI_COMMIT_REF_NAME would no longer be the source branch of the merge request, which was causing issues for our users (https://gitlab.com/gitlab-org/gitlab-ce/issues/60822), we fixed that in !27663 (merged) by adding setting the COMMIT_REF_NAME back the the source branch name of the merge request.

This means that checking out CI_COMMIT_REF_NAME would mean checking out something different than CI_COMMIT_SHA, which given the CI_COMMIT_* prefix could be confusing.

Should we allow a grace period and encourage users to use CI_MERGE_REQUEST_SOURCE_BRANCH_NAME to get to the branch name in merge request pipelines and then eventually expose the ref name for the CI_COMMIT_SHA that's being run in the build?

---

The following discussion from !27663 (merged) should be addressed:

• @reprazent started a discussion: (+5 comments)

  What would be the value of CI_COMMIT_SHA? Because I think we might want to keep these variables consistent with the other CI_COMMIT_* variables.

  I think it might be confusing if the ref name here points to a different SHA then the commit the build is actually running from.

  Should we add new variables for that instead and document the change?

  Would slugifying the refs/merge-requests/[:iid]/[merge|head] break anything for users?

  @ayufan What are your thoughts on this, as you've commented in the issue already?