Add support for selective code owner removals

What does this MR do and why?

Related to #344632 (closed). The initial proposal was built and discussed at length, but reworked slightly based on UX feedback (to make the functionality clearer and easier to document). What we have now agreed on:

Under Project settings > Merge request approvals > Approval settings

Separate Remove all approvals, add Keep all approvals and Remove approvals by Code Owners if their files changed. and switch to radio buttons to choose between the 3 options.

If the MR is updated with new changes, re-approval should only be necessary if the files requiring approval are changed.

Migrations

lee@cc-gdk-2:~/gitlab-development-kit/gitlab$ bundle exec rake db:migrate:up:main VERSION=20220619212618 RAILS_ENV=development
main: == 20220619212618 AddSelectiveCodeOwnerResetsToProjectSettings: migrating =====
main: -- add_column(:project_settings, :selective_code_owner_resets, :boolean, {:default=>false, :null=>false})
main:    -> 0.0106s
main: == 20220619212618 AddSelectiveCodeOwnerResetsToProjectSettings: migrated (0.0126s) 

lee@cc-gdk-2:~/gitlab-development-kit/gitlab$ bundle exec rake db:migrate:down:main VERSION=20220619212618 RAILS_ENV=development
main: == 20220619212618 AddSelectiveCodeOwnerResetsToProjectSettings: reverting =====
main: -- remove_column(:project_settings, :selective_code_owner_resets, :boolean, {:default=>false, :null=>false})
main:    -> 0.0036s
main: == 20220619212618 AddSelectiveCodeOwnerResetsToProjectSettings: reverted (0.0073s) 

Screenshots or screen recordings

How to set up and validate locally

1. Create a project with a CODEOWNERS file and a few rules (you will need to ensure some distinct owners) e.g.

   

2. Create some files which match those rules and push up to main/master.

   

3. Enable Project settings > Merge request approvals > Approval settings > Remove approvals by Code Owners if their files changed.

4. Create a new branch changing files impacting all rules (bonus points for including a standard/non-codeowner rule)

5. Create a merge request

6. Approve all rules (you will likely want to impersonate users through the admin > users page)

7. Push a new commit changing just one file impacting one codeowner rule

8. Ensure only that rule (and if you created a standard/non-codeowner rule) is reset.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.