Added create method in MemberApproval and db unique constraint

Context

• As part of &13328 we are working on Adding controls for Admins/Owners to manage Billable Members promotion/addition in Groups and Projects (still a WIP feature).
• This issue deals with adding that Promotion control for the Invite New Member flow.
• When PromotionManagement conditions are applicable(code), we want to queue the User/Member Addition/Promotion request if that addition/promotion will increase the Billable count for the SM instance (We will bring this to SaaS eventually)
  • This would mean queuing that request in a MemberApprovals table
  • Allowing Admin to view the requests and approve/reject it (being handled in different issues)

What does this MR do and why?

This entire flow exists together in a draft mr here. That was done to get early review from domain owners, this is a break down version of that MR.

This MR is part of a wider change, broken down for ease of review
Database changes + Model Changes to Queue Member Approvals	This MR does this
Add new Service to queue Invited Members, that will make use of the method added here	!154555 (merged) (draft)
Call Service through Creator Service add_members method	!154562 (diffs) (draft)

This MR:

• Adds new method to create or update MemberApprovals
  • we already have a method to queue existing member's promotion request, but as part of the Invite New member's flow, we will be replacing that method with the new one introduced here.
• Modifies unique pending promotion db and validation constraints.
  • Initially we had planned to allow multiple pending promotion requests per user, per namespace (each with different new-access-levels)
  • But based on a recent discussion where we decided to keep only one record per user per source here, so the constraint and validation changes are to account for that.
  • The method added to "create_or_update" also aligns with this decision
• Updates spec for the same

EE: true Changelog: changed

ref: #433179 (closed)

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

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.