Transfered projects do not consider the new feature: enable/disable instance level Shared Runners on the group level

Summary

Bug related to this feature: Allow user to enable/disable instance level Shared Runners on the group level

When a project with shared-runners enabled (default value for any new project) is transferred to a group with shared-runners disabled; group settings won't be applied.

Also when going to the transferred project settings (CI/CD -> runners); the shared-runners are considered disabled with the message "Shared runners disabled on group level", thus making it impossible to disable shared-runners manually.

Steps to reproduce

1. Create a new group
2. Go to the group's settings -> CI/CD -> Shared runners, and disable option: Enable shared runners for this group
3. Create a new project under no group (or a group with shared runner enabled)
4. Transfer new project to group created in step 1
5. Clone new project
6. Add basic gitlab playbook (=gitlab-ci.yml)
7. Push code
8. Check in CI/CD section of the project (in Gitlab's UI) that the job is started and executing by a shared runner
9. Observe that in the project's settings (CI/CD -> runners) it is not possible to disable shared-runners manually

Example Project

Here is a group where I disabled shared-runners: https://gitlab.com/issue-testing

I then created this project under no group and transferred it. You can see that the job was actually executed by a shared runner.

I tried again by creating an other project under a group this time (with shared runner enabled on group level), and the problem persist.

What is the current bug behavior?

Share-runners policy on group level is not respected for newly transferred projects.

What is the expected correct behavior?

Apply shared runners policy from group on newly transferred projects.

Output of checks

This bug happens on GitLab.com.