Allow users of the Direct Transfer API to skip certain relations
<!--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=432809)
</details>
<!--IssueSummary end-->
### Proposal
A Direct Transfer pipeline goes through each stage defined in [lib/bulk_imports/projects/stage.rb](https://gitlab.com/gitlab-org/gitlab/blob/6b9484b79d2b973b392db3999dd6df3e5bbeb566/lib/bulk_imports/projects/stage.rb). In most cases this is fine. Either the user has little or no data in a given stage, or lots of data they want to keep.
This proposal aims to assist when a user wants to migrate from one GitLab instance to another and can't or doesn't want to migrate certain things.
We could extend the functionality provided by the [Direct Transfer API](https://docs.gitlab.com/ee/api/bulk_imports.html) to allow for a list of excluded relations:
```bash
curl --request POST --header "PRIVATE-TOKEN: $GTLB_TOKEN" "https://gtlb.example.com/api/v4/bulk_imports" \
--data '{
"configuration": { /* abridged */ },
"entities": [
{
/* abridged */
"excluded_relations": "ci_pipelines,releases"
}
]
}'
```
Some stages[^stages] aren't included in the source bundle, but are requested from the source instance at import time. This means it's easier to specify the list of unwanted relations when importing, rather than when exporting.
[^stages]: members, badges, snippets_repo, wiki, uploads, LFS objects, design
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-->
<!-- Label reminders
Use the following resources to find the appropriate labels:
- Use only one tier label choosing the lowest tier this is intended for
- https://gitlab.com/gitlab-org/gitlab/-/labels
- https://about.gitlab.com/handbook/product/categories/features/
-->
issue