[nexus] Make 'dataset' columns for IP address optional

[smklein]

This is part of an effort to make datasets usable without an explicit service managing them (e.g., in the context of Support Bundles).

Related to #6042
Fixes #2000

[jmpesp]

@smklein I'm concerned about datasets that should have an* associated IP and port but don't: they can be deleted or not included during creation. How do you feel about a constraint that says those fields have to be non-null based on the kind field?

[smklein]

@smklein I'm concerned about datasets that should have an* associated IP and port but don't: they can be deleted or not included during creation. How do you feel about a constraint that says those fields have to be non-null based on the kind field?

I'm willing to do this -- especially for Crucible -- but if you look at all the spots where I updated "accessing the IP/port columns to cope with being Optional", you might have noticed: it's only Crucible that's accessing the IP/port pair from the dataset record.

This doesn't mean that other services (Cockroach, Clickhouse, etc) don't care about the IP / port values, I think they're just accessing them from a different spot:

omicron/schema/crdb/dbinit.sql

Lines 3230 to 3248 in 2ba2846

	-- SocketAddr of the "primary" service for this zone
	-- (what this describes varies by zone type, but all zones have at least one
	-- service in them)
	primary_service_ip INET NOT NULL,
	primary_service_port INT4
	CHECK (primary_service_port BETWEEN 0 AND 65535)
	NOT NULL,
	-- The remaining properties may be NULL for different kinds of zones. The
	-- specific constraints are not enforced at the database layer, basically
	-- because it's really complicated to do that and it's not obvious that it's
	-- worthwhile.
	-- Some zones have a second service. Like the primary one, the meaning of
	-- this is zone-type-dependent.
	second_service_ip INET,
	second_service_port INT4
	CHECK (second_service_port IS NULL
	OR second_service_port BETWEEN 0 AND 65535),

And, when we want to look up these values, we look them up via DNS (or at least, we're trying to trend in that direction).

Regardless, patched this in 5122118