Refactor handling of commit sha in pipeline editor

What does this MR do?

For #335074 (closed)

In the pipeline editor, the commit sha currently comes from two sources: rails injection and graphql. This data is then saved locally in the apollo cache.

This refactor aims to unify this so that the pipeline editor only refers to one single source of truth. In doing so, we remove the rails injection and instead query the latest commit sha from the pipeline_editor_app. The result is then propagated down to the child components as props.

This also means removing the local mutation and cache data, which removes the need to directly manage the data ourselves. We can just let apollo work its magic this way.

Breakdown

I broke down the changes into five commits, which might make the code easier to review:

Commit	Change
19dffac5	Query commit sha via graphql (from the pipeline_editor_app)
e8dcec11	Remove commit sha from rails injection (has backend changes)
010a43d0	Propagate commit sha down to the child components. This also removes instances of writing to the cache.
1d1da5b9	Remove local apollo query and mutation for commit sha
fab12f9b	Update frontend specs. Since this does not introduce new features, this is mostly making sure that the tests are set up correctly to fetch the data from graphql instead of the cache.
6ea9673f	(From review) Add specs for the commit sha polling.

What does this change affect?

Features affected by commit sha:

• ✅ pipeline status should update to the correct pipeline/commit when switching branches
• ✅ pipeline status should update to the correct pipeline/commit when committing branches
• ✅ include config should reflect the config in the current branch

Screenshots or Screencasts

Switching branches

Switching_Branches

On Commit

On Commit

Merged YAML changes

Merged YAML changes

How to setup and validate locally

You can view the pipeline editor for your project through CI/CD > Editor.

There are three cases to test:

Switching Branches

1. Select a new branch from the branch switcher dropdown.
2. Verify that the commit sha and pipeline should update in the pipeline status.

On Commit

1. Commit a new branch through the form at the bottom of the pipeline editor.
2. Verify that the commit sha and pipeline should update in the pipeline status.

Merged YAML changes

1. Create your .gitlab-ci.yml file and add the included config.

   main-branch-job:
     script:
       - echo
   
   include:
     - local: 'include-file.yml'

2. In two separate branches, make sure to add different contents for the include-file.yml:

   Branch 1:

   included-job:
     script:
       - echo "This job was added with include"

   Branch 2:

   included-job-2:
     script:
       - echo "This job was added with include in my branch, not master"

3. Go to the pipeline editor and switch between the two branches.

4. Check the "View Merged YAML" tab for each branch and verify that the content changes in the included config.

Does this MR meet the acceptance criteria?

Conformity

• [-] I have included changelog trailers, or none are needed. (Does this MR need a changelog?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.
• This change is backwards compatible across updates, or this does not apply.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)