Changes Usage Quota member query for performance

What does this MR do and why?

Changes the Usage Quota page to stop counting and displaying the number of pending/awaiting members (part of the User Cap for groups feature).

Previously, we would count the number of pending members and conditionally display an alert if that count is greater than 0.

The downside to that approach is that the query performs really badly and for some of our larger customers, this would result in a failure of our apdex target (5 seconds).

In this MR, we switch to checking if there are any? records, which modifies the query with a LIMIT, to sufficiently drop the query performance to within the apdex target.

As a result, we now stop displaying the count in the UI, as confirmed here.

Please note, the query performance is still not good, but it is a significant improvement from where it was at, the following statistics are from using one of our largest groups:

• Old query on a cold cache: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/23463/commands/75376

  Time: 1.134 min  
  - planning: 12.835 ms  
  - execution: 1.134 min  
    - I/O read: 1.500 min  
    - I/O write: 0.000 ms  
  
  Shared buffers:  
  - hits: 325248 (~2.50 GiB) from the buffer pool  
  - reads: 100121 (~782.20 MiB) from the OS file cache, including disk I/O  
  - dirtied: 3012 (~23.50 MiB)  
  - writes: 0  

• New query on a cold cache: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/23463/commands/75378

  Time: 4.271 s  
  - planning: 11.135 ms  
  - execution: 4.260 s  
    - I/O read: 5.377 s  
    - I/O write: 0.000 ms  
  
  Shared buffers:  
  - hits: 325248 (~2.50 GiB) from the buffer pool  
  - reads: 100121 (~782.20 MiB) from the OS file cache, including disk I/O  
  - dirtied: 3012 (~23.50 MiB)  
  - writes: 0  

Longer term, hopefully significant improvements can be made via initiatives such as https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/7130+

Shorter term, this should improve the experience for some of our larger groups.

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

1. Ensure the User Caps feature is enabled:

     Feature.enable(:saas_user_caps)

2. Goto a Group and set a low user cap, e.g. 1 (Group -> Settings -> General -> User Caps)
3. Invite a new member to your group which will add them as a pending member (Group -> Manage -> Members -> Invite Member)
4. View the Group Usage Quotas page (Group -> Settings -> Usage Qutoas)

You should see the new alert

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.