generic `authz` types could be more type-safe

[davepacheco]

Right now, in nexus/src/authz/api_resources.rs, we have "typed" and "generic" resources. "typed" resources are resources to which we will allow users to assign roles -- the Fleet, Silos (eventually), Organizations and Projects. Everything else is a generic FleetChild or ProjectChild with a type alias, like type Instance = ProjectChild. The reason is just that there's a bunch of boilerplate for each resource, and given the current policy, nothing actually cares what type anything is, so it was easier to do it this way.

I only recently appreciated that this means you can pass an authz::Project where an authz::Instance is expected, which seems pretty dangerous. That alone convinced me that we're better off with well-typed versions of these things.

It may help simplify the problem if we eliminate the constructors at each level for constructing child resources (e.g., Organization::project(project_id) -> Project). That was a convenient pattern when I expected you'd be building these by hand. But these are generally going to be built by the lookup_resource macro. If we make this Project::from(Organization) instead, we can update the macro to use that, and it may make it quite a lot easier for us to generate the full set of authz types (since you don't have to generate any type-specific methods).

[davepacheco]

Copying some of my own notes here: I wonder if we can replace everything at the Project level and below with one "impl" type, but provide type-safe wrappers for them. What I really want to achieve is to share the struct contents and the impls of helpers like parent(), and impls of ApiResource and ApiResourceError...but still keep things type-safe (ie. so you can only create a VpcSubnet as a child of a Vpc, not a Project)

[davepacheco]

Fixed via #895.