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 borne out by the fact that deleting all this stuff doesn't affect anything else, i.e., doesn't cause any tests to fail.

[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.

[david-crespo]

I've checked this over 10 times and can't see any downside, so I'm going to merge it. Made #8554 as a followup to simplify further by using an enum for the role names.