Before this PR, we had no "Accept invite" functionality.
A few days ago, @chrsmith added the email-sending feature in https://github.com/sourcegraph/self-serve-cody/pull/777, and I tweaked it a bit in https://github.com/sourcegraph/self-serve-cody/pull/781. The current PR wires up the rest of the flow, and lets the user actually use the invite.

Three changes happen in this PR:

1. I extracted CodyAlert and CodyContainer because I wanted to reuse them on pages other than CodyManageTeamPage.
2. I split the remaining styles of CodyManageTeamPage into InviteUsers and TeamMemberList.
3. I added the new page at /cody/invites/accept. It makes a back-end call to POST /team/${teamId}/invites/${inviteId}/accept, and if it succeeds, redirects the user to /cody/team/manage, otherwise displays an error message.

For easier review, no. 1 and no. 2 are in one commit, and no. 3 is in a different commit.

There are a few problematic parts, but first, to have a common understanding of the process, I'll describe the user flow and how the user interacts with our system when using invites.

This is a common happy path:

1. An admin goes to https://cody-services-dev.sgdev.dev/cody/subscription, clicks the "Create a Cody Pro team" button, and buys two seats.
2. Same admin goes to https://cody-services-dev.sgdev.dev/cody/team/manage and invites a colleague. This action sends an email to the colleague
3. The colleague receives the "You've been invited to join a Cody Pro team!" email and clicks the big "View invite" button.
4. The colleague arrives at the https://cody-services-dev.sgdev.dev/cody/invites/accept page, through a link that looks like this: https://cody-services-dev.sgdev.dev/cody/invites/accept?inviteID=018f9b13-ddd1-7f1f-b030-29b6f8fc77dd&signin=OpenIDConnect&teamID=018f9b13-5bf7-77cc-b192-c2fcac17ad94 (has an inviteID, and a teamID argument).
5. The page checks the validity of the inviteId+teamId combo.
6. It's valid, so the user gets redirected to https://cody-services-dev.sgdev.dev/cody/team/manage and sees a list of the admin and themself.
7. 💰

Problems I'm seeing:

1. (larger problem) With this architecture, anyone can accept the invite. This is problematic in at least two ways:
   • If the user forwards the email to someone (maybe even through an autoforward), that someone can redeem the invite for them.
   • If the user is logged in with a different user on sourcegraph.com, their invite will be redeemed for the wrong user. This can be as easy as just clicking the wrong SSO icon when presented. To solve this, the admin can kick out and re-invite the colleague, but it's still awkward.
   • Suggestion 1: back end: In step no. 5, compare the logged-in SAMS user's email address to the email address of the invite (here) and fail if they don't match.
   • Suggestion 2: front end: If suggestion no. 1 doesn't work for some reason, we can add the invited email address to the link, like https://cody-services-dev.sgdev.dev/cody/invites/accept?inviteID=018f9b13-ddd1-7f1f-b030-29b6f8fc77dd&signin=OpenIDConnect&teamID=018f9b13-5bf7-77cc-b192-c2fcac17ad94&email=invited.person@company.com (notice the last part), and then check it against the logged in user's email address on the front end. Fail if they don't match.
2. (smaller problem) The "View invite" button actually links https://cody-services-dev.sgdev.dev/cody/invites/accept, which straight away accepts the invite. The button text is misleading.
   
   • Suggestion: Let's use the copy "Accept invite".
3. (smaller problem) The name is missing from the email:
   • Suggestion: Let's just say "Hey, friend," or something. We won't know the name of most users.
   • Suggestion 2: I'd treat this as a nice-to-have because we don't even have a DB field for it, but in case the invitee already has a Sourcegraph account, use their first name.

That said, the current PR could be fine as-is; we just need to be mindful of these two caveats and fix them (or consciously ignore them) as a follow-up.

Test plan

I've tested it manually. The flow is not perfect (A "Bad gateway" response displays on the "Accept" page for a split-second AND a "Forbidden" response is returned on the "Manage" page), but it accepts the invite correctly and the user shows up in the list:

Same on the admin's side:

I'll fix these problems in a follow-up PR.