Moving of neighbour items was done recursively - this
was extremely expensive when multiple items had to be moved.

This change optimizes the code to find nearest possible gap where
items can be moved and moves all of them with single update query.

Starts from START_POSITION when there are no existing
positions.

Also improves the test to actually test the behavior

RelativePositioning module was heavily dependent on the Issue model.
This changes makes it easier to reuse the functionality provided by
RelativePositioning in other models.

Needed by: https://gitlab.com/gitlab-org/gitlab-ee/issues/12196

Updates changed method names and fixes spec failures

1. When every issue has a relative position set, we don't need to
   perform any updates, or calculate the maximum position in the parent.
2. If we do need to calculate the maximum position in the parent, many
   parents (specifically, groups with lots of projects) leads to a slow
   query where only the index on issues.relative_position is used, not
   the index on issues.project_id. Adding the GROUP BY forces Postgres
   to use both indices.

Partially addresses #47424.

And use .rubocop.yml to exclude paths we don't care,
rather than using the cop itself to exclude.