feat: working POST API for Project Observations

[miketheman]

Please review commit-by-commit to make reviewing easier.

Notes:

• There's a bunch of TODOs to highlight conversations or choices.
• Does have a GET /danger-api/echo endpoint
• Does have a POST /danger-api/projects/{name}/observations endpoint that validates the inbound payload (kinda sorta) and persists in the database
• Does NOT include the database migration to add the new column on the User table - I'll submit that as a separate PR if we want to proceed this way (it's a kludge). Here: feat: migration for User.is_observer #15238
• Does NOT leverage Macaroon Caveats - so a User-scoped API Token from a user that is_observer will be allowed to POST. This is not a good long-term solution, but can likely work well enough to gather some data.
• Does NOT include any tests yet - I wanted to get some structural approaches done here first. Tests! But they rely on the migration PR being merged first.

[ewdurbin]

This is a really nice and straightforward PR thanks to a lot of previous legwork. Thanks for that @miketheman.

Overall I will be confident in approving this for merge once we have a couple of things inplace:

• Sufficiently annoying/obvious signs to users that we are not committing to any API ergonomics or features. Think "danger" and "unstable" and "preview" and "dragons here" type verbiage in versions and or urls.
• A confidence in our malware observation payloads such that we feel comfortable that they will be actionable immediately, and not too likely to be discarded or useless long term. I see that [DRAFT] PyPI Observation Reporting Payload #14503 has some good updates on approaches here. Thanks for that.
• A side-effect to committing a malware observation that creates a conversation in the PyPI Security inbox. This ensures that any reporters that adopt the API won't have their reports "lost". It will integrate this effort into our current pipeline fairly seamlessly! I recommend attaching the observation as a .json attachment given...
• Some documentation that observations associated with deleted objects will also be deleted until we implement soft-deletes.

[miketheman]

Thanks for the review!

I've addressed the first couple of bullets so far, and will continue to work on the next two.

[miketheman]

This is pretty much ready to go, while I work out some more details in a follow up, unless reviewers see them as merge blockers:

• add danger-api endpoint for Releases
• add Observations and API to Files, Users

Keep in mind: Only superusers or folks we've set User.is_observer flag will be able to post with a user-scoped API Token, until we do more on the caveats/permissions front (soon).

[ewdurbin]

Overall I am very impressed/happy with the iteration on our API infrastructure/machinery here!

I have one concern regarding local development that I think would be wise to consider before merge just so that the feature can be worked on by anyone, not just those of us with HS access.