Modify query for group.first_owner

What does this MR do and why?

For #421852 (closed)

Context

group.first_owner currently runs the scope: has_many :owners to obtain owners.first, which produces the following query:

SELECT "users".*
FROM   "users"
       INNER JOIN "members"
               ON "users"."id" = "members"."user_id"
WHERE  "members"."type" = 'GroupMember'
       AND "members"."source_id" = 22
       AND "members"."source_type" = 'Namespace'
       AND "members"."requested_at" IS NULL
       AND "members"."access_level" = 50
ORDER  BY "users"."id" ASC
LIMIT  1 

Query plan for gitlab-org namespace: https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/21677/commands/70448

to obtain the user who is an OWNER in the group.

As you can see, this query involves a join between the users and members table.

Problem

Now that we are moving to the cells architecture, different tables will belong to different physical databases, so cross-joins between them are not possible to perform.

users is being moved to clusterwide table, while members will be a cell-local table, so we should avoid cross joins between them.

So, the query to find the first owner user can be changed to

first_owner_member = all_group_members.all_owners.order(:user_id).first
first_owner_member&.user

which produces two separate queries to find the user, without the use of cross-joins

SELECT   "members".*
FROM     "members"
WHERE    "members"."type" = 'GroupMember'
AND      "members"."source_id" = 22
AND      "members"."source_type" = 'Namespace'
AND      "members"."requested_at" IS NULL
AND      "members"."access_level" = 50
ORDER BY "members"."user_id" ASC limit 1

Query plan: https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/21677/commands/70450

SELECT "users".*
FROM   "users"
WHERE  "users"."id" = 1 limit 1

Query plan: https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/21677/commands/70454

I am ordering by members.user_id because the existing query does ORDER BY "users"."id" ASC LIMIT 1, so this would maintain parity between the old and the new approach.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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.

Related to #421852 (closed)