Update API to match resolution of RFD-322

[just-be-dev]

In RFD-322 we reached consensus to update our API design to be ID first¹. This issue is to track the work necessary to complete that transition.

Migration

• Update RFD-322's determination section for clarity
• Update instance endpoints first as a PoC of the approach v1 instance APIs as per RFD-322 #1957
• Update disk endpoints RFD-322 -- /v1/ Disks API #2008
• Update networking endpoints RFD-322 Networking #2057
• Update organization endpoints RFD-322: Add /v1/ endpoints for organizations and projects #2050
• Update project endpoints RFD-322: Add /v1/ endpoints for organizations and projects #2050
• Update snapshot endpoints RFD-322: /v1/snapshots #2347
• Update users and groups RFD-322: users list (+ filter by group) #2423
• Update image endpoints
• Update system endpoints
• Update remaining endpoints
• Delete non-V1 endpoints

Cutover

• Improve all the v1 error messages
• Update tests to use v1 APIs
• Mark non-v1 endpoints as deprecated (depends on allow endpoints to be marked as deprecated dropshot#503)
• Cleanup authz test ignores
• Update authz test to be able to verify both id and name path requests to the same endpoint.
• Cleanup any TODO-v1 comments
• Cleanup nexus action names as per this comment
• Move all possible contents of a handler into the handler method (context)
• Add comments on each individual property in the selectors to note how they relate to each other (context)
• Update CLI usages in docs for v1 API and new CLI #2409

---

Footnotes

1. I'm working on synthesizing the discussions and decisions into an an actual determination section ↩

[just-be-dev]

Something to follow up on..

In #2347 the snapshot_create method in the nexus layer requires that the project_lookup it uses to be passed by value instead of reference. That's because when calling a function hanging off of a lookup (like disk_name in this case) it actually consumes the lookup. Meaning you can't do multiple things on a lookup. Given that that's the case, I'm not sure it makes sense to pass lookups by reference. You almost want to guarantee that the lookup is being moved to whatever Nexus function is calling it.

This is more of a logical correctness thing than anything. I would like to have the API calls being mostly consistent though.

[karencfv]

Do we expect people to be able to change their usernames? If not maybe we should keep GET /system/user/{user_name} with name instead of ID? 🤔

[david-crespo]

@karencfv I think that's right. Those are built-in users whose names do not change.

omicron/common/src/sql/dbinit.sql

Lines 1711 to 1717 in 7394180

	/*
	* Users built into the system
	*
	* The ids and names for these users are well-known (i.e., they are used by
	* Nexus directly, so changing these would potentially break compatibility).
	*/
	CREATE TABLE omicron.public.user_builtin (