Revert user already exists to members API

What does this MR do and why?

reverting most of !80177 (merged), due to gitlab-com/gl-infra/production#6351 (closed)

Synopsis

A customer is sync'ing memberships to some projects they have every hour

• instead of checking to see if members exist first...they are just trying to re-invite them on the members API and the check we are putting back in was stopping the larger queries that run to add a member in the service layer from running
  • now those expensive queries are running and causing issues with db saturation on our side

Before this revert

A pre-existing member could be re-invited via the members API.
This caused expensive queries to be ran during that process at the Members::CreatorService level.

• noteable queries:
  • query for all existing members and requestors
  • query all members and requestors
  • validate access level query

After this revert

A pre-existing member will be detected, when adding a single member, at the API level and will not go down into the Service layer, thus foregoing those queries.

How does this fix the issue in gitlab-com/gl-infra/production#6351 (closed)?

The nature of the members API use by the customer was saturating the DB by spawning many of those service level queries. This reversion will mitigate that as the API layer will reject terminate those API hits before they reach the service layer(where the expensive DB queries exist).

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.