Investigation - allow user to re-import failed relations and relations created after previous import
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=375041)
</details>
<!--IssueSummary end-->
<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab.
The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). -->
### Problem to solve
When migrating groups with projects with GitLab Migration, if migrating some of the projects within a group fails, ~~there is currently no way for user to retry only failed projects, leaving the user with an only option to retry the whole group import.~~ the user can re-import chosen project(s) via API. However, that creates new project(s) on each re-import and not fully imported project(s) need to be deleted by the user.
We [discussed](https://gitlab.com/gitlab-com/dev-sub-department/section-dev-request-for-help/-/issues/147#note_1537613653) creating a new API endpoint which imports a single relation into an existing project (E.g. a user makes a request to import 'merge_requests' relation and uploads `merge_requests.ndjson` file.) without adding an ability of filtering out already imported records & blindly trying to import everything that was provided ([comment](https://gitlab.com/gitlab-com/dev-sub-department/section-dev-request-for-help/-/issues/147#note_1539194137)). However, that could produce duplicates and have unexpected results.
We could instead:
- "fix the first import"
- filter out things that were already imported when performing chosen relation re-import OR make all the jobs idempotent and performing chosen relation re-import (would that need to be triggered by the user?)
- try to import all the records that failed to be imported at the first run (as we keep the record of what has failed. Should we run that always or should user trigger that?)
- and perform secondary import
- perform a second import that would import whatever was added after the first import (similarly to https://gitlab.com/gitlab-org/gitlab/-/issues/424492+)
<!-- Label reminders
Use the following resources to find the appropriate labels:
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
issue