[3/n] [reconfigurator-cli] drop dependency on reconfigurator-execution

[sunshowers]

The only functions from reconfigurator-execution currently pulled in are these
helper methods. Move them into nexus-types so that reconfigurator-cli no longer
has to pull in the execution crate and all of its dependencies (particularly
nexus-db-model and nexus-db-queries).

There is one downside, which is that Overridables's #[cfg(test)] methods
are no longer marked that way. However, it does make the overrides available to
places such as the reconfigurator-cli. (It would be interesting to have a
test-related overlay feature in omicron, i.e. a testing feature in many of
our crates, but we don't have that yet.)

I had to move some of the silo fixed data into nexus-types as well -- as part
of that I took the opportunity to switch to const methods for a couple of
UUIDs.

[andrewjstone]

@sunshowers this is great! Thanks for speeding up crate builds!

[jgallagher]

Is it weird that the *-types crate is gaining constants? I don't object to this, but I wonder if this is a gap in our crate organization or naming somehow.

[sunshowers]

I guess I view this as roughly in the same ballpark as, say, the CockroachDB version constants:

omicron/nexus/types/src/deployment/planning_input.rs

Lines 357 to 377 in dda39e3

	/// The hardcoded CockroachDB cluster version we want to be on, used in
	/// [`Policy`].
	///
	/// /!\ WARNING: If you change this, there is no going back. /!\
	pub const POLICY: CockroachDbClusterVersion =
	CockroachDbClusterVersion::V22_1;
	/// The CockroachDB cluster version created as part of newly-initialized
	/// racks.
	///
	/// CockroachDB knows how to create a new cluster with the current cluster
	/// version, and how to upgrade the cluster version from the previous major
	/// release, but it does not have any ability to create a new cluster with
	/// the previous major release's cluster version.
	///
	/// During "tick" releases, newly-initialized racks will be running
	/// this cluster version, which will be one major version newer than the
	/// version specified by `CockroachDbClusterVersion::POLICY`. During "tock"
	/// releases, these versions are the same.
	pub const NEWLY_INITIALIZED: CockroachDbClusterVersion =
	CockroachDbClusterVersion::V22_1;

. Slightly out of the ordinary but I don't think there's a better place to put them. (You could put them in a crate of their own but that seems excessive, since there aren't any dependencies).

[davepacheco]

Thanks. Practically this looks like a great change.

As @jgallagher alluded to: there's something a little off about some of the stuff that's moving into nexus-types. Some of these are fixed data constants. silo_dns_name() is super tiny but also semantically pretty significant. The blueprint-to-{internal,external}-DNS-configuration is also semantically pretty load-bearing. The net result seems like a big win! And it's definitely fine as-is. It just remains surprising that the "types" crate would also have implementation for execution behavior and I'm not sure what the takeaway is.

[davepacheco]

Is it easy to check if this affects the output of cargo xtask ls-apis? I'm a little worried this is going to make everything that uses nexus-types appear to be a client of the DNS servers. I think that'll be avoided by one of the existing exceptions.

[sunshowers]

cargo xtask ls-apis apis showed no difference before and after.

If we're worried about this dependency, it's probably best to move the types out into a separate internal-dns-types crate.

[sunshowers]

Ah I see what's going on -- this is because internal-dns (both the types and the resolver) depends on dns-service-client for the types. I guess the way to address that is to define the types in another crate, then use replace -- similar to other places we've broken dependencies from _client to _types.

[davepacheco]

Good. I think that as I hoped, this is being covered by this rule:

omicron/dev-tools/ls-apis/api-manifest.toml

Lines 390 to 400 in 1a6343e

	[[dependency_filter_rules]]
	ancestor = "internal-dns"
	client = "dns-service-client"
	evaluation = "bogus"
	note = """
	internal-dns depends on dns-service-client to use its types. They're only used
	when configuring DNS, which is only done in a couple of components. But many
	other components use internal-dns solely to read DNS. This dependency makes it
	look like everything uses the DNS server API, but that's not true. We should
	consider splitting this crate in two to eliminate this false positive.
	"""

As long as you see no change in the output, there's no (new) problem here.

[sunshowers]

Thanks for the reviews!

The blueprint-to-{internal,external}-DNS-configuration is also semantically pretty load-bearing.

True -- though there's a fair bit of load-bearing implementation code in nexus-types already, e.g.

omicron/nexus/types/src/deployment/planning_input.rs

Lines 711 to 719 in dda39e3

	match self {
	SledPolicy::InService {
	provision_policy: SledProvisionPolicy::Provisionable,
	} => match filter {
	SledFilter::All => true,
	SledFilter::Commissioned => true,
	SledFilter::Decommissioned => false,
	SledFilter::Discretionary => true,
	SledFilter::InService => true,