Use IN operator optimization on group list MRs

What does this MR do and why?

This MR applies the optimization documented here: https://docs.gitlab.com/development/database/efficient_in_operator_queries/ on the list group MRs endpoint.

It targets API calls that match parameters known to result in queries that contribute a significant share to error budget degradation on that endpoint see dashboard. The 86% are queries with params like so: [page, per_page, state, with_merge_status_recheck]. The parameters lead to queries that have an appropriate index (i.e idx_mrs_on_target_id_and_created_at_and_state_id) to match the optimization constraints of https://docs.gitlab.com/development/database/efficient_in_operator_queries/

Additional work can be done to cover other indexes and broadly apply the optimization, but to reduce complications and not invest too much time, I am targeting known offenders before extending this and refactoring to include other queries we can improve against.

References

Spike: identify opportunities to improve top-le... (#585222)

Query plans

New query plan: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/51047/commands/151167

Old query olan: https://postgres.ai/console/gitlab/gitlab-production-main/sessions/50743/commands/150446

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.