Remove meta-programming from merge strategy class choice

Problem

grouppipeline execution often has to interact with the auto-merge logic when it comes to supporting the merge train feature.

Since we don't own auto-merge logic we are less familiar with it.

It becomes difficult to track the flow of the auto-merge logic because it uses meta-programming to determine the class used and therefore we can't grep for where AutoMerge:::MergeWhenChecksPassService the class is called.

Example:

    def get_service_class(strategy)
      return unless all_strategies_ordered_by_preference.include?(strategy)

      "::AutoMerge::#{strategy.camelize}Service".constantize
    end

We handle this with a comment now but that is less than ideal as strategies are added. Only 1 strategy has the comment.

Fix

Refactor get_service_class to use a map rather than constantizing the strategy name:

    def get_service_class(strategy)
      return unless all_strategies_ordered_by_preference.include?(strategy)

      strategy_to_class_map[strategy]
    end

    def strategy_to_class_map
      {
        STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS => AutoMerge::MergeWhenPipelineSucceedsService,
        STRATEGY_MERGE_WHEN_CHECKS_PASS => AutoMerge::MergeWhenChecksPassService
      }
    end

This will also allow us to:

  1. Search for where the AutoMerge classes are instantiated
  2. Change the name of the class without changing the strategy names and we are currently violating the bounded context rules with our class name. We need to move the merge train auto merge strategies to the MergeTrains Bounded Context.
Edited by Allison Browne (PTO 12/19-1/2)