[sudomateo]

Added the following system APIs to create, read, delete, and list certificates.

silo_certificate_create  POST    /v1/system/certificates
silo_certificate_delete  DELETE  /v1/system/certificates/{certificate}
silo_certificate_list    GET     /v1/system/certificates
silo_certificate_view    GET     /v1/system/certificates/{certificate}

These APIs are mostly identical to the current /v1/certificates APIs, with the difference that callers must now specify the silo. This allows clients that authenticate to one silo to manage the certificates for another silo. For example, platform engineering teams that operate within a management silo to create silos for their users.

Relates to SSE-498.
Relates to oxidecomputer/terraform-provider-oxide#875.

[david-crespo]

Made some changes:

• Test certificate access for non-admin silo member: a silo collaborator should 403 on list/create and 404 on view/delete. This was true but there was no test for it.
• Scope /v1/certificates/{id} to current silo: visible_outside_silo = true turns off the lookup's built-in check that a resource is in the caller's silo, so a fleet admin could GET or DELETE another silo's cert by ID through the silo-scoped endpoint. Added a helper current_silo_certificate_fetch_for, which makes sure the caller's silo matches the cert's silo, plus a regression test. This one is kinda debatable: maybe you want a fleet admin to be able to use the endpoint across silos, but I think that's both more confusing and more complicated to implement.
• Rename to silo_certificate_*, shorten docs: the system endpoints about silos mostly use the silo_ prefix (silo_create, silo_policy_*, silo_ip_pool_list, etc.). In the doc comments, I dropped some redundant bodies, and dropped a false claim from 2023 about sorting by creation date.
• Fix stale certificate create/delete comments: the create comment said authz happens "below" in the datastore, but it now happens up front. The delete comment pointed at certificate_create(), but that comment moved to certificate_create_for_silo().

[david-crespo]

Tested by prototyping the console UI in oxidecomputer/console#3410. Just want to check a couple more things before I approve.

[sudomateo]

This one is kinda debatable: maybe you want a fleet admin to be able to use the endpoint across silos, but I think that's both more confusing and more complicated to implement.

I left this as-is because this is also true for the /v1/users API. A fleet admin can use that endpoint to fetch a user across silos, given their ID.

The rest of the feedback makes sense.