sled agent client: use SocketAddr/SocketAddrV6 for socket addresses instead of strings

[davepacheco]

In the Sled Agent API, on the server side, most variants of OmicronZoneType have an address: SocketAddrV6 field or something like it. These wind up getting turned into Strings in the OpenAPI spec. So the Progenitor-generated client-side structure OmicronZoneType has these fields as Strings, too. This is starting to get pretty unwieldy because various code paths need to parse these values and deal with errors that shouldn't be possible.

Some notes on this from @ahl:

• The behavior of turning SocketAddr into string in the OpenAPI spec comes from schemars.
• There isn't a json schema format specifier like there is, say, for IpAddr: { "type": "string", "format": "ip" }
• schemars also doesn't generate a "$ref" for SocketAddr.
• If we did generate a $ref, we could use replace to swap in SocketAddr for the local type. This doesn't work right now because replace operates on named types, and there's no named type for this. It's just a String.

It sounds like the options here are:

1. On the server, everywhere we use these, apply #[schemars(with = "some_function_that_emits_a_schema")] so that the JsonSchema for these has its own named type. On the client, replace that type with std::net::SocketAddr. I imagine we'd want to do this for SocketAddr, SocketAddrV4, and SocketAddrV6.
2. Almost the same as the above, but define our own newtype for these on the server (instead of using the annotation) to add a name to the JsonSchema.
3. Alternatively, fork schemars to change the schema it generates for the SocketAddr family of types.

[jgallagher]

3. Alternatively, fork schemars to change the schema it generates for the SocketAddr family of types.

It looks like there's not an open issue on schemars about this; have we asked out of band?

[sunshowers]

Working on this, by using replace for all of OmicronZonesConfig -- required to break circular dependency between types and client crates as part of work to split the sled-agent API into a trait (a long chain of reasoning leads to this as the almost-necessary thing to to do. I'll try doing a writeup about this)

[sunshowers]

Addressed in #6138 -- writeup is in the PR summary.