EarlyNetworkConfigBody: make rack_network_config non-optional

[jgallagher]

The main thrust of this PR is that it gives us a coherent versioning story for the types kept in the bootstore. There's a block comment in the sled-agent/types/versions/src/impls/early_networking/early_network_config_serialization.rs module that explains the steps necessary to add a new EarlyNetworkConfigBody version, allowing us to safely rev RackNetworkConfig.

I wanted to walk through this with a worked example, so I made two seemingly-backwards-incompatible changes to EarlyNetworkConfigBody that I'll claim are actually completely fine:

• Make EarlyNetworkConfigBody::rack_network_config non-optional
• Remove EarlyNetworkConfigBody::ntp_servers

For the first: the only creators of EarlyNetworkConfigBody are RSS and Nexus's sync_switch_configuration background task, and both of them unconditionally supply Some(rack_network_config). If there was some code path in the past where this could be None, it's long gone, and any deployed rack with None would have already failed to come back online after a reboot.

For the second, I'll submit three pieces of evidence that it's safe to remove ntp_servers:

1. I removed all the places where we populated this field, but there were no places we read it.
2. The NTP servers alone are useless; we allow customers to specify them by name, which means we'd also need DNS servers along side them for them to be useful.
3. The actual NTP server configuration flows through OmicronZoneType::BoundaryNtp { .. }, the config for the boundary NTP zone. It includes both upstream NTP servers and upstream DNS servers.

Staged on top of #9944. Closes #9801.

(I'm not sure why we're still seeing a 10,000+ line diff from OpenAPI; maybe because I'm stacked on top of another PR instead of main? I assume that will go away once #9944 lands.)

[sunshowers]

(I'm not sure why we're still seeing a 10,000+ line diff from OpenAPI; maybe because I'm stacked on top of another PR instead of main? I assume that will go away once #9944 lands.)

Yeah, this is the case Dave and I discussed in the update watercooler today -- we don't consider API versions blessed until they land on main so they won't be converted to stubs. In this PR there's a change to v24 (the operation ID change), which wouldn't be allowed once you're on main.

Once the previous PR lands on main, v24 will become a Git stub. You can preview what happens with:

cargo xtask openapi generate --blessed-from-git origin/john/bootstore-versioning

(Though trying this out locally made me realize that with our RFD 619 recommendation to update the operation ID, the API document will be different, and we'll ask you to restore the blessed version from Git instead of doing it ourselves -- this is an expected case which we should handle better. Will fix -- edit: fixed in #9947).