Investigate refactor of mergeable method

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

• @dskim_gitlab started a discussion:

  I think we should perhaps consider making a clear distinction between we are checking if we can enable auto_merge vs can this MR be merged. Every time I look at all this skip_* it feels very messy and hard to follow when we want to skip and when we don't. I feel the main reason is that we're conflating the two.

  The code doesn't really explain why we're skipping rebase check and conflict check sometimes. I have to follow the call chain up to understand the reasoning. Should we consider adding a separate method called something like can_enable_auto_merge and keep it as pure mergeable? check without any skips? I wonder these code should belong to strategy service themselves. 🤔

!222317 (comment 3088396554)

Yeah, I see it's called twice. It just seems wasteful to do mergeability checks twice within the same response given that it would execute merge_to_ref again which could be expensive. Also, we're calling mergeable_state? and mergeable_git_state? again even when we have already executed them in BaseService#availability_details. Is it really necessary calling mergeable? on top? 🤔

Perhaps available_auto_merge_strategies could just return auto merge strategies based on user permission and other config/status except the mergeability status? We could then check the mergeability only once? Frontend could then use both info to decide what to show?

It could potentially require a bigger change, but I think this needs to be looked at. I think that's related to my earlier comment about it being hard to follow so perhaps we can consider this as a part of that too. WDYT?

!222317 (comment 3088396550)

By the way, it's also unclear why we had to set skip_rebase_check on EE only so it'd be great if we can consider this as well in the follow up issue.