Re-import chosen relation between between source and destination project when migrating by direct transfer
<!--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=430789) </details> <!--IssueSummary end--> ### Problem When importing projects with a large relation (a lot of MRs or issues in a project), part of the relation items might not get imported (some MRs are not imported). At the moment user can: - Retry importing the full project (aka create another copy of the project) and hope that this time all relation items get migrated - Use [Single Relation Endpoint](https://docs.gitlab.com/ee/api/project_import_export.html#import-a-single-relation). This however doesn't support user contribution mapping for regular users (only for admin users). The process of using the endpoint is cumbersome and manual. For example, users must **manually** export the project using file-based export or the Direct Transfer Relations API. In the latter case, users must **manually** create a file compatible with the Single Relation Endpoint and import that file via the endpoint. None of them is time-efficient and a good UX. ### Proposed solution When some relation items (e.g. MRs) don't get migrated, user should be able to: - See clearly feedback, that a specific MR could not be imported, because of e.g. it cannot be written to DB due to not meeting validations (it's not possible to import it at all, so it doesn't make sense to retry) - Or re-import the previously failed to be imported relation items (or the whole relation) to the same project on destination, so that the project on destination has all MRs (same state as on source). The contribution mapping should apply. Only destination project Owners could re-import. The assumption is that this functionality in UI would rely on an API endpoint, so the first iteration of this feature could be exposing that endpoint. Unless that technically not a good idea. ### Technical details ### Documentation Extended endpoints needs to be documented. User documentation updated. <!-- 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