Tracking issue: move views and params out of common

[david-crespo]

This is meant to capture the substantial followup work based on #369, #374, and #386.

Now that we have generated clients for internal communication, each app should own the structs that define its request bodies (params) and responses (views). The difficulty is that there are a lot of changes to be made before we reach the desired end state, way more than would be reasonable to put in a single PR. Refactors should be done as quickly as possible, but there's going to be a short time where we're in an intermediate state. Also doing a bunch of refactors while we're all hurrying for Milestone 3 is not a good idea. So we're going to have to finish this afterward.

• Simple public views only used in Nexus
  • Project and Organization (done in Structure for moving views and params structs out of common #374)
  • Vpc and friends
• Sled agent things
  • DiskEnsureBody, DiskStateRequested, ShareRequest, ShareResponse (done in Sled agent views/params shuffling #386)
  • InstanceHardware, InstanceEnsureBody, InstanceRuntimeStateRequested
• Runtime state things
  • DiskRuntimeState — kind of interesting because both nexus and sled agent have endpoints that use this struct. this means they should probably each own their own and define a conversion to the other's. There's also the fun fact that Nexus stores this in the db. lots of lines in the diff because it's used in like 60 places
  • InstanceRuntimeState — same deal

This is not a complete list, I'll add more as I go through them.

[david-crespo]

there's going to be a short time where we're in an intermediate state

welp

[david-crespo]

I spent a little time trying to move RouterRoute and its params friends into Nexus, but it was quite difficult to untangle what should go where. They all depend on the enums RouteTarget and RouteDestination, which are also used in several other places.

I also spent a bit of time attempting UpdateArtifact and UpdateArtifactKind, but in this case the complication comes from it being used in both Sled Agent and Nexus. I think this should be defined in Nexus and then Sled Agent should mostly rely on the types from the generated Nexus client, but I had trouble making this compile because of the interdependent macros (sled agent client gen and nexus client gen).

This is emblematic of the situation with the remaining views.

[david-crespo]

I think we got as far as we're going to get on this.