Delete builtin_roles

[david-crespo]

This came up in a meeting with @davepacheco — storing the roles in the DB and letting them be listed through the API is a legacy idea with no practical application that we know of. When I heard that I was curious how much could be deleted.

Fundamentally, all this machinery I've deleted was just in service of the role_view and role_list endpoints, which let you get something like this list:

fleet     admin
fleet     collaborator
fleet     viewer
silo      admin
silo      collaborator
silo      viewer
project   admin
project   collaborator
project   viewer

I think we thought this would be a dynamic list of roles, but all these things are hard-coded. As far as I can tell there is no relationship to the actual authorization system — this is basically just an unrelated copy of that stuff. This claim will (hopefully) borne out by the fact that deleting all this stuff doesn't affect anything else.

[david-crespo]

I'll probably want to update this comment too. If the premise of this PR is correct, the comment was wrong to say the role_builtin table is involved in authorization.

omicron/nexus/auth/src/authz/mod.rs

Lines 68 to 115 in ca58574

	//! ## Role lookup
	//!
	//! Users, roles, and API resources are all stored in the database. Naturally,
	//! so is the relationship that says a particular user has a particular role for
	//! a particular resource.
	//!
	//! Suppose a built-in user "cookie-monster" has the "viewer" role for a Project
	//! "monster-foodies". It looks like this:
	//!
	//! ```text
	//! +---> table: "project"
	//! | +-------------------------+-----+
	//! | | id | name | ... |
	//! | +-------------------------------+
	//! | +-> 123 | "monster-foodies" | ... |
	//! | | +-------------------------+-----+
	//! | |
	//! | | table: "user_builtin"
	//! | | +------------------------------+
	//! | | | id | name | ... |
	//! | | +------------------------------|
	//! | | | 234 | "cookie-monster" | ... |
	//! | | +--^---------------------------+
	//! | | |
	//! | | +---------------------------------------------------------------+
	//! | | |
	//! | | table: "role_builtin" |
	//! | | primary key: (resource_type, role_name) |
	//! | | +---------------+-----------+-----+ |
	//! | | | resource_type | role_name | ... | |
	//! | | +---------------+-----------+-----+ |
	//! +---|-> "project " | "viewer" | ... | |
	//! | | +---------------+--^--------+-----+ |
	//! | | | |
	//! | +-|--------------------+ |
	//! | | | |
	//! | | | table: "role_assignment" |
	//! | | | (assigns built-in roles to users on arbitrary resources) |
	//! | | | +---------------+-----------+-------------+-------------+---+ |
	//! | | | | resource_type | role_name | resource_id | identity_id |...| |
	//! | | | +---------------+-----------+-------------+-------------+---+ |
	//! | | | | "project " | "viewer" | 123 | 234 |...| |
	//! | | | +--^------------+--^--------+----------^--+-----------^-+---+ |
	//! | | | | | | | |
	//! +-|-|----+ | | +------------+
	//! +-|--------------------+ |
	//! +----------------------------------------+
	//! ```

[davepacheco]

I don't have a strong feeling either way on the PR overall but this note got me thinking: is there value in having this? It'd probably be better if we actually enforced that the (resource_type, role_name) column in role_assignment were a valid foreign key. Given how static this is today, these could as well be enum values instead. 🤷

[david-crespo]

Yeah, I think converting role to an enum would make a lot of sense.