Domain invitation/ userdomain role consolidate logic

[allly-b]

Issue description

The models domain invitations and userdomain roles were made for a less complex system, but now that we have the org model domain invitations and user domain roles are proving to have architectural issues that increase code complexity unnecessarily. Theoretically, we do not need to actually have two different models anymore and we could reduce code complexity by resolving these models into one and getting rid of the concept of a "retrieved" domain invitation.

Some of the problems with these models:

Domain invitations are made when a user is not part of our system yet, and would made to only have 2 states, invited and retrieved, but canceled was added in later. Once and invite is retrieved, keeping it in our system actually makes it harder to reinvite the same user back to a domain again, and we never look at retrieved invites in our code so we really should just remove retrieved invites.

However, we then also have user domain roles which get created with an invite is "retrieved" or when a user is part of the system. User domain roles have a "role" value that is unneeded at this point as it only has the value "manager" and we have no plans to add other roles (nor do we check this value).

In the org model domains views the seperation between these two models also increases the code complexity as you need to check both of them to see how many domains a user (or invited user) is assigned.

Acceptance criteria

• Create plan for domain invitation/user domain role complexity reduction #3553
• implement the plan to reduce code complexity, these should be sub issues of this ticket. (note this can be delegated to other engineers)

Additional context

keep in mind that we have existing data on stable we would not want to lose, this could mean we need to migrate data into a combined table with a script and keep domain invitations and userdomain roles as part of our schema for a little bit in order to validate all data has been migrated appropriately.
Note this means, part of the sub issues should be eventually removing the old tables once all data has been verified (if we determine that combining the tables into one is truly feasible.

Links to other issues

• blocks Investigate combining portfolio invitations and user portfolio permissions #3554