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