Stop sending user to pages they don't have access to on invites

What does this MR do and why?

• fix: send users to dashboard projects page instead of group/project activity page when registering email does not match invite email
  • when invite email does not match the email they register with, the member will not be associated with the user, so it is not correct to send them to the group/project activity page at that point.
• fix: automatically accept invites for existing users on sign in for edge case described below.

note

This MR fixes the above issue by removing the stored location in the invites controller.

However, that then causes an edge case where:

1. A unregistered user is invited by email.
2. User is then either created by an admin with that email or LDAP synchronization changes a current user's email to the invited email.
3. That unsigned in user then clicks the invite email link.
4. Expected behavior is that the user is then redirected to the group/project activity for that membership.
   • So we needed another mechanism to handle that location redirect after sign up
   • However, the invite wasn't accepted either and we never noticed since the spec/features/invites_spec.rb's group creation was public. Therefore, we needed to detect that testing gap by making the group private in the feature spec and then accepting the invite automatically. This matches the current behavior of existing users when invited(automatic acceptance) and also the pending invitations logic on newly registered users that match an invite's email.

verified locally by running all invite feature specs since some are quarantined and won't run in CI

• spec/features/invites_spec.rb
• ee/spec/features/registrations/saas/invite_flow_spec.rb

Screenshots or screen recordings

scenario	Before	After
user created by admin after invite
user signs up with different email than invite

How to set up and validate locally

User created by admin after invite

1. Create a new private group.
2. Invite a someone via email to that group(role doesn't matter).
3. As an admin, create a new user via http://gdk.test:3000/admin/users using the same email that was invited.
4. Log out or use an incognito window.
5. Using rails letter opener(http://gdk.test:3000/rails/letter_opener/), find the reset your password email and reset it.
6. Using rails letter opener(http://gdk.test:3000/rails/letter_opener/), find the invite email and click on the link.
7. Sign in with that new user.
8. Notice redirection to the private group that the user was invited to.
   • master branch: shows 404/not found page.
   • this branch: shows group activity page w/o 404 message

User registers with different email than invite email

1. Ensure GDK not setup to simulate SaaS. Unset and restart GDK if it is.
2. Create a new private group.
3. Invite a someone via email to that group(role doesn't matter).
4. Open an incognito window.
5. Using rails letter opener(http://gdk.test:3000/rails/letter_opener/), find the invite email and open it in the incognito window.
6. Sign up, but change the prefilled email address to something different.
7. You may need to confirm email after this step, look for email and click link and sign in.
8. Fill out onboarding screen(only need role) and submit.
9. Notice redirection:
   • master branch: to the private group that the user was invited with 404/not found page.
   • this branch: shows projects dashboard page.

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.

Related to #424036 (closed)