Devise an approach to properly sequence issue relative_positions after 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=535477)
</details>
<!--IssueSummary end-->
RelationFactory was calculating relative positions for imported issues based on the relation index.
We encountered two problems with this approach:
* The query generated while finding the current max relative position for an imported project fails for very large groups. (https://gitlab.com/gitlab-org/gitlab/-/issues/458367)
* Direct Transfer imports relations in batches. The offset was reset for each batch, effectively shuffling each batch of issues together. (https://gitlab.com/gitlab-org/gitlab/-/issues/458367#note_2440355479)
We should devise an approach for setting the relative position on imported issues that satisfies the following:
- Avoids the gap issue caused by preserving the relative positions from the source instance (i.e. jumping from 10 to 1,000,000)
- Does not cause a database timeout when finding the max relative position across huge groups
- Is compatible with the Direct Transfer approach of importing issues in batches, which makes maintaining a single offset challenging.
issue