feat(dev-toolbar): Add organization derived API applications

[cmanallen]

Overview

To enable the dev-toolbar feature we want to allow public, third-party applications (think "Login with CodeCov" but self-serve and for all organizations) to fetch Sentry data on behalf of a Sentry user. To accommodate this I've:

• [x] Added a "scoping_organization_id" column to the ApiToken model and replica.
• [x] Added a "organization_id" column to the ApiApplication model.
• [x] Updated the oauth flow to set the "scoping_organization_id" on the ApiToken when an "organization_id" is present on the ApiApplication.
• [x] Updated the middleware responsible for gating access.
• [x] Added a resource for managing organization ApiApplication instances.

Goal

The goal is to allow customers to authenticate with Sentry from a third-party origin.

How It Works

1. A customer defines an ApiApplication instance tied to their organization.
2. This ApiApplication contains the valid origin and redirect locations for an authorization request for that organization.
3. The ApiApplication generates a client-id value. This value is public and is passed to the Javascript SDK's initializer (e.g. sdk.init(..., client_id=xyz).
4. The SDK reads this client-id and initiates Sentry's oauth flow (/oauth/authorize/) either through a hard-redirect or a pop-up window. Making sure to specify the client-id in the request parameters.
5. Sentry appends a url fragment containing the access token and redierects back to the requester's application.
6. The token is now accessible by the third-party program and can be used to make API requests to Sentry.

CORS

To manage CORS issues, the login flow will be initiated from an iframe with a sentry.io origin.

Supporting Documentation

PRD: https://www.notion.so/sentry/FY-25-Q2-Dev-Toolbar-e2a259c063634f93a6c3d89584e812d8

Security

Public clients present two problems:

1. First there is a phishing risk where a malicious third-party is given an access_token and uses that token to extract sensitive data from Sentry servers.
2. Second there is a risk that a legitimate third-party provider may use an access_token to read data from other organizations.

To address these issues I've done two things:

1. ApiApplications will only generate credentials if the user is a member of the organization.
2. ApiTokens will be scoped to the ApiApplication's organization_id. a. Requests for data outside of the organization will be denied.