Use ARRAY(subquery) instead of EXISTS to avoid planner mis-estimation

What does this MR do and why?

Spin off from Use a materialized CTE for by_commit_sha's meta... (!253023). We have received reports of the endpoint GET /api/:version/projects/:id/repository/commits/:sha/merge_requests returning 500s due to query timeout, logs: https://log.gprd.gitlab.net/app/r/s/yinaT

Some of these slow queries are a known issues and are follow-up items to fix from switching to the partitioned merge_request_diff_commits table. In particular, this MR attempts to fix the slow MergeRequest.by_commit_sha scope, by forcing a filter on diff ids, to avoid poor joins as a result of poor query planner estimation. It does this behind an FF for safety.

References

https://gitlab.com/gitlab-org/gitlab/-/work_items/627135+

Query Plans

New plan: https://console.postgres.ai/gitlab/projects/gitlab-production-main/sessions/56800/commands/161304

Old plan: https://console.postgres.ai/gitlab/projects/gitlab-production-main/sessions/56800/commands/161306

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.