Recreate records when moving issues

What does this MR do and why?

Based on the discussion in !156640 (comment 1957676511)

Recreate records when moving issues

When moving an issue from one project to another, we create a new issue in the other project. With it we also changed the references like epic_issues or work_item_parent_links to the new issue.

The work_item_parent_links table uses namespace_id as sharding key. This key also needs to be updated to the new project's namespace_id. However, it's recommended to not change sharding keys but treat the records as immutable and re-create them with the new references.

As we also want to add namespace_id as sharding key to epic_issues, we now recreate the epic_issue and work_item_parent_link records with the new issue reference. We already have a trigger on insert to set the namespace_id to the one of the new project.

Changelog: fixed EE: true

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

1. Create an epic
2. Add an issue to that epic
3. /move the issue to another project

Then check in the rails console:

old_issue = Issue.find(old_issue_id)
new_issue = WorkItem.find(new_issue_id)

old_issue.epic_issue #=> []
old_issue.work_item_parent_links #=> []

new_issue.epic_issues #=> shows the link to the epic
new_issue.parent_link # => link to the epic and work item/issue
new_issue.parent_link.namespace_id # => same as new_issue.namespace_id