Deleting security policies at a project level with subgroup-level inherited policies returns inaccurate data

Summary

Steps to reproduce

1. Create a subgroup
2. Create a project within the subgroup
3. Create policies on both subgroup and project (which creates a parallel security policy project)
4. Ensure project has bee linked to the project, then modify the link to point to subgroup security policy project
5. Attempt to delete a policy from project
6. Observe that you will be redirected to the subgroup policy project (presumably based on the policy project link), even though the policy you want to edit/delete is a direct policy. Also notice that the policy page list may be inaccurate for the project when displaying Direct vs All sources of policies. This latter part may require creating/editing policies between changing the link. I'm not 100% sure on how this occurs.
7. Modify policy project link to point to project policy project again
8. Observe that the proper list of policies are displayed again and delete/edit redirects you to the proper page

Example Project

https://gitlab.com/gitlab-examples/wayne-enterprises/wayne-financial

What is the current bug behavior?

See loom video.

What is the expected correct behavior?

It should be possible to properly edit/delete policies at the project level as a project owner regardless of the linked security policy project.

Or it shouldn't be possible to inherit and link the same security policy project to avoud confusion.

Relevant logs and/or screenshots

See loom shared earlier.

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)
(we will only investigate if the tests are passing)

Possible fixes

Avoid directly linking projects to security projects that are already inherited.

Implementation plan

1. Return an error response in ee/app/services/security/orchestration/assign_service.rb:27 if the project already inherits the security policy project.
2. Show an error message in the UI saying that an already inherited project can't be linked.
3. When a new inheritance is created, unlink the directly linked security policy project
4. Create a background migration to clean up duplicated links.