authz: protect GET for Projects (and prepare for more)

[davepacheco]

This change does a few things:

• adds authz checks for the "GET Project" API endpoint
• refactors the Project fetch/lookup functions, exactly analogously to what I did under add authz checks for top-level Organization endpoints #592 for Organizations. This lays groundwork for protecting the rest of the project-level API endpoints as well as the endpoints for Instances, Disks, VPCs, etc.
• renames organization_lookup_id() (which was created in add authz checks for top-level Organization endpoints #592) to organization_lookup_path() for consistency with project_lookup_path(). The idea here is that for every resource we'll eventually have a $resource_lookup_path() function that takes the (API) path of names that identify it. For example:
  • organization_lookup_path(organization_name) (in this change, renamed from organization_lookup_id)
  • project_lookup_path(organization_name, project_name) (new in this change, this simplifies a bunch of call sites in nexus.rs)
  • disk_lookup_path(organization_name, project_name, disk_name) (future change)
  • etc
• rewraps some comments and string literals that were over 80 columns

This is all a lot simpler than it sounds. Most of the changes are pretty mechanical.

Hopefully those examples explain why I called these *_lookup_path, and why I renamed the Organization lookup function to match, even though it only has one name in its argument list.

I'm trying to keep these PRs small and manageable. As a result, this is still an intermediate state. There will be more cleanup to be done as I get to the more deeply-nested endpoints. (As an example: in functions like Nexus::project_update_vpc, we used to first look up the Organization id, then the Project id, then the Vpc id. Now we use the new DataStore::project_lookup_path to directly fetch the project id, then we do a separate lookup for the Vpc id. In a follow on change I expect this to be simplified further using a new DataStore::vpc_lookup_path.)

[david-crespo]

The .1 here feels a little opaque. One alternative would be to use a struct instead of a tuple for the lookup result (so here you would do .model or something), but maybe that's too heavy.

[david-crespo]

Looks good! The lookup_path concept makes sense to me. (I might have called it lookup_by_path though 🙂)