Update the list and the counter after inline role change

What does this MR do and why?

Part of #449139 (closed) , this iteration reacts to an inline role change to refetch count and the list of members, who are pending a promotion.

Why we need that?

When a users role is changed from non-billable to billable by a user — it might either create a promotion request or auto-close one. So when an inline role is changed — we need to react to that by updating the counter of Pending promotions (which is stored in VueX) and update the list of pending promotion members (which is a self-contained Apollo app).

note: in the future, the pending promotions tab should become lazy loaded, so we might have only counter update, but not the list update.

promotion_requests_inline_update

Proposed solution:

This MR emits a Vuex action from the inline role change UI (role_updater.vue), that then does two things:

• Dispatches a new event to update the Promotion requests count
  this is needed to update the (count) badge of the promotion requests tab, which is used also to show/hide that tab
• if promotions app is mounted (ee/members/promotion_requests/components/app.vue) then we reset it and refetch the data
  this is needed to update the list on the promotion requests tab, and reset any pagination if it was present

What were other approaches considered?

The main trick here is to connect members/role_updater.vue to the promotion_requests/app.vue and the VueX store. We could have other approaches:

• Invalidate Apollo cache data, which will trigger a data refetch. This however won't account for pagination, if it was applied in the component.
• Create a @roleChange="emit('roleChange')" emit/handle chain through the members app, and then dispatch that event down to the EE pending promotions app. But it would look like a manual broadcasting of events
• We could emit this event to VueX and find the promotion_requests/app.vue instance in the DOM (not sure how to do that, something like vue-test-utils findComponent style), and then call a method on it to refetch it's data
• have a v-if on the tab contents of the promotion requests, meaning it would reload each time the tab is selected (suboptimal for back-n-forth switches)

MR acceptance checklist

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

Screenshots or screen recordings

-/-

How to set up and validate locally

1. Have an Ultimate License, and simulate Ultimate Self Managed setup (export GITLAB_SIMULATE_SAAS=0)
2. Enable FF Feature.enable(:member_promotion_management)
3. Go to admin settings / General / Sign-up restrictions and check the "Approve role promotions" checkbox
4. Create promotion requests:
   1. Visit any Group members management page as an owner of that group (e.g. http://127.0.0.1:3000/groups/gitlab-org/-/group_members)
   2. try promoting a non-billable GUEST member to a DEVELOPER role (this member should be non-billable on the whole instance, i.e. have a highest role as guest, see !149094 (comment 1869616221) for details)
   3. you should see a banner saying "Role change request was sent to the administrator." — this means a promotion request has been created
5. What this MR does:
   1. When a first promotion request is created — the Promotion requests tab should appear
   2. With new role changes — the counter on Promotion request tab should get updated, as well as the tab content.