Handle members who are existing hierarchy members

What does this MR do and why?

When adding members to a group hierarchy who are using the UserCap feature, they are added in either an active or awaiting state, depending on whether or not they have reached the assigned user cap value.

When the user cap has been reached, if we add an already active member of the hierarchy to another group within the hierarchy, they should be considered active rather than awaiting, because they are already taking up a billable seat within that hierarchy.

This MR addresses this problem by modifying the activation logic accordingly.

Stats for the query being used to achieve this are:

Warm stats:

https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/8213/commands/29109

Time: 7.207 ms
  - planning: 2.041 ms
  - execution: 5.166 ms
    - I/O read: 0.000 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 3369 (~26.30 MiB) from the buffer pool
  - reads: 0 from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

Cold stats:

https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/8213/commands/29108

Time: 1.077 s
  - planning: 9.379 ms
  - execution: 1.068 s
    - I/O read: 1.048 s
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 2466 (~19.30 MiB) from the buffer pool
  - reads: 909 (~7.10 MiB) from the OS file cache, including disk I/O
  - dirtied: 83 (~664.00 KiB)
  - writes: 0

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

1. Ensure the SaaS USer Cap feature flag is enabled:

     Feature.enable(:saas_user_caps)

2. With a group hierarchy similar to:

        Group A 
         /  \
    Group B  Group C

3. Add a user (User A) to Group B
4. Check they are active:

     Member.last.active?
     => true

5. Set the user cap to an appropriate value so that the cap can be considered reached:

     group_a.namespace_settings.update(new_user_signups_cap: 1)

6. Add to add a user to Group C (not User A from above)
7. Check they are awaiting:

     Member.last.awaiting?
     => true

8. Add User A to Group C as an owner
9. Check they are active:

     Member.last.active?
     => true

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.