Refactor issue move to not require group_id param

What does this MR do and why?

For #341562 (closed), I want to support move_before_id and move_after_id in the issue creation mutation so that we can position the issue upon creation.

Right now, our reorder service requires a group_id as a "container" for searching those issue IDs. Otherwise, it tries to search in the same project. See: https://gitlab.com/gitlab-org/gitlab/-/blob/9df0ef280c4c9c95b3dd8d8a95c19b7c10434577/app/services/issues/update_service.rb#L228-233

This is unnecessary logic because all we need to care about is that both those IDs are under the same positioning scope defined by https://gitlab.com/gitlab-org/gitlab/blob/393e4a5c2d92208c82d934a5a47e5e3025425b6b/app/models/issue.rb#L265-267. In other words they're under the same Namespace / Group hierarchy.

I don't want to add a group_id parameter to the issue creation mutation that only affects the move IDs because it is confusing and does not make sense. It's also possible for the mutation code to just get the project's root ancestor and pass that in to the update service as the group ID, but that's confusing and is just a workaround.

With this refactor, Issues::UpdateService won't need the group ID param and uses Issue.relative_positioning_query_base as the SSOT to determine whether the neighbor IDs given are valid.

This fixes #211864 (closed) too.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.