Return partial_success when Apply pending promotions fails if user is already billable

What does this MR do and why?

Promotions requests for existing billable users never gets applied (and is stuck in pending state) if there is only one promotion request and that promotion request fails during applying the promotion.

One example of such failure during applying pending promotion happens when the user gets added on a higher role up the hierarchy.

eg: Bob got queued to be added on SubGroup1 on Developer Role.

• If before Bob gets approved(or auto approved), Bob gets added on a Maintainer role on the parent Group (via LDAP, SAML, or by Admin themselves all whitelisted channels)
• When applying pending promotions the request will fail to apply because of this code check, basically the access needs to be greater than or equal to the access level they have been assigned on the parent group.
• If this is the only promotion request for the user, the entire batch will fail as all pending promotions fail to apply(code)
• This will keep the pending promotions request in "pending" state forever.

This MR adds a check to validate if the user is already billable, and if they are then to resolve the pending promotion and return partial_success from the service. This aligns with point 2 of the discussion about the behaviour of this service, where we decided to return success if the user is billable.

References

#524621 (closed)

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.