Remove foreign key ci_group_variables.group_id as we have loose fK

What does this MR do and why?

In !77322 (merged) we already added a "loose foreign key" to replace this foreign key. Now that this has been running fine in production we should be OK to remove the foreign key altogether.

This was added in a post-deployment migration as we want to ensure that they have the correct code running with the loose foreign key in place before we remove the foreign key to ensure that there isn't any lost deletes.

Migration output

Up

== 20220104060049 RemoveForeignKeyCiGroupVariablesGroupId: migrating ==========
-- transaction_open?()
   -> 0.0000s
-- foreign_keys(:ci_group_variables)
   -> 0.0032s
-- remove_foreign_key(:ci_group_variables, :namespaces, {:name=>"fk_33ae4d58d8"})
   -> 0.0040s
== 20220104060049 RemoveForeignKeyCiGroupVariablesGroupId: migrated (0.0145s) =

Down

== 20220104060049 RemoveForeignKeyCiGroupVariablesGroupId: reverting ==========
-- transaction_open?()
   -> 0.0000s
-- foreign_keys(:ci_group_variables)
   -> 0.0030s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE ci_group_variables\nADD CONSTRAINT fk_33ae4d58d8\nFOREIGN KEY (group_id)\nREFERENCES namespaces (id)\nON DELETE CASCADE\nNOT VALID;\n")
   -> 0.0028s
-- execute("ALTER TABLE ci_group_variables VALIDATE CONSTRAINT fk_33ae4d58d8;")
   -> 0.0057s
== 20220104060049 RemoveForeignKeyCiGroupVariablesGroupId: reverted (0.0221s) =

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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.

Related to #348269 (closed)