Follow-up from "Verify fast-forward merge advances the target branch"

The following discussions from !239586 (merged) should be addressed:

• @hfyngvason started a discussion:

  For a follow-up: I think we should also harden app/services/merge_requests/create_ref_service.rb against rebase collapse. That would have prevented the auto-rebase variant of this issue, and address the same issue for merge trains.

• @hfyngvason started a discussion:

  Nit (not blocking): CreateRefService also accepts a SHA for first_parent_ref, so we could actually resolve this once and make the target_sha: optimistic lock a mandatory argument to fast_forward!. I wouldn't bother with it now, but maybe after cleaning up the flag.

• @hfyngvason started a discussion:

  Nit (not blocking): Since this is a fast-forward, commit_sha == prior_target_sha is equivalent to checking src_sha == prior_target_sha before attempting #ff_merge.