RFD-322 Networking

[just-be-dev]

See #2028

This PR adds V1 versions of the developer facing networking APIs. Firewall rules aren't in this PR. I'll do that in a follow up.

New Endpoints

All endpoints here are scoped via query parameters by their parent selectors. So for vpc-subnets if you provide the vpc by name, you'll also need to provide the project. If the projected is specified by name you'll need the org.

So /v1/vpc-subnet?vpc={vpc_id}, /v1/vpc-subnet?vpc={vpc_name}&project={project_id}, etc

# Scoped via  ?project={project}
GET    /v1/vpcs       # List VPCs
POST   /v1/vpcs       # Create a VPC
GET    /v1/vpcs/{vpc} # Get a VPC
DELETE /v1/vpcs/{vpc} # Delete a VPC

# Scoped via  ?vpc={vpc}
GET    /v1/vpc-subnets          # List VPC subnets
POST   /v1/vpc-subnets          # Create a VPC subnet
GET    /v1/vpc-subnets/{subnet} # Get a VPC subnet
DELETE /v1/vpc-subnets/{subnet} # Delete a VPC subnet

# Scoped via  ?vpc={vpc}
GET    /v1/vpc-routers          # List VPCs
POST   /v1/vpc-routers          # Create a VPC
GET    /v1/vpc-routers/{router} # Get a VPC
DELETE /v1/vpc-routers/{router} # Delete a VPC

# Scoped via  ?router={router}
GET    /v1/vpc-router-routes         # List VPC router routes
POST   /v1/vpc-router-routes         # Create a VPC router route
GET    /v1/vpc-router-routes/{route} # Get a VPC router route
DELETE /v1/vpc-router-routes/{route} # Delete a VPC router route

# Scoped via ?instance={instance}
GET    /v1/network-interfaces             # List network interfaces
POST   /v1/network-interfaces             # Create network interface
GET    /v1/network-interfaces/{interface} # Get a network interface
DELETE /v1/network-interfaces/{interface} # Delete network interface

For a quick overview of the entire API (and the changes introduced in this PR) check out the nexus_tags.txt file

Notable changes

• I pulled app level network interface functions out into their own file.
• I've slowly started to update the naming convention of app and datastore level functions to be less nested (and closer to the operation names) as per this comment. It's a little bit inconsistent now but the intent is to do a larger follow up to clean these all up. At present I'm just updating them as I come across them.
• I've begun moving all possible contents of an http entrypoint into its handler for more timing information as per this comment

[just-be-dev]

I moved this over to the params file to be co-located with the other resource params that were already there.

[david-crespo]

Whew, this is a BIG one

[david-crespo]

Not something to be addressed in this PR, but it's a little silly that these are all the same. If we called it resource in all cases maybe they could share the struct. Something like:

#[derive(Deserialize, JsonSchema)]
pub struct NameOrIdPath {
    pub resource: NameOrId,
}

[just-be-dev]

Yeah, the ultimate intent here I think is to have it be generated by a macro. Unfortunately the name matters as it shows up in documentation, the API spec, etc.

[karencfv]

We did that at "previous job" (have a common "resource" struct), and it was such a pain when we needed to add additional fields for a new version, it ended up being a spaghetti nightmare 😅

[just-be-dev]

I relocated the network interface logic in its own file. We break this resource at the data store layer, might as well be consistent with it.

[just-be-dev]

I'm going to push forward here. Please, if folks have any feedback don't hesitate to add it after the merge. I'm more than happy to follow up with any fixes or re-work that may be needed.

[bnaecker]

Sorry for the delay! I'm nearly done with my comments!

[bnaecker]

Hey Justin! This is an enormous amount of work. Thank you so much for taking it on, this looks like a big improvement. I have a few comments, all related to documentation and comments. There's nothing in the code itself that appears out of order. Thanks again, great work!