warehouse, tests: v2 caveats

[woodruffw]

WIP.

Closes #10792.

[woodruffw]

Specific TODOs:

• Design the V2 caveat body
• Allow V2 caveats to be minted (should we replace the current user-created-by-form tokens with them?)
• Figure out how authentication works with "userless" macaroons (as OIDC-minted ones will be, unless we decide to associate them with the user who enabled the OIDC publisher)

[woodruffw]

Re: v2 caveat body: here's my rough plan:

version: 2
permissions: {
  kind: "user" | "projects"
  projects: [str]?
  not_before: int?
  expires: int?
}

For OIDC-minted tokens, kind would always be "projects" and not_before and expires will always be present.

[woodruffw]

I'm going to repurpose this PR to generally refactor how Macaroons are handled in Warehouse. In particular:

• It's wasteful and inflexible of us to store the entire serialized caveat state with each db.Macaroon model. The only reason we do that is to present a user-friendly table in the account management view; instead, we should store a list of "permission" strings that mirror the permissions of the crafted macaroon.

• Instead of TopLevelCaveat dispatching to V1Caveat and V2Caveat, we should fully leverage Macaroons' ability to have multiple first-party caveats. In other words, both V1Caveat and V2Caveat should be registered via satisfy_general. That, in turn, will have implications for how we actually structure "v2" caveats.

[di]

Going to dismiss my review request until those changes are made!

[woodruffw]

I'm gonna close this and start anew, since the TopLevelCaveat decision was an initial misdesign.

[woodruffw]

Replacement #11122.