Prevent Nexus from initializing until CRDB is populated

[smklein]

Stops Nexus from booting until CRDB appears initialized, at least once.

This change allows other bootstrapping aspects of the control plane to initialize Nexus and CRDB concurrently, as Nexus will await CRDB formatting before launching itself.

[davepacheco]

(Not sure if you're still looking for a review here. I think we discussed offline having RSS not start Nexus until database populate was done. I think that's a lot cleaner.)

To record some thoughts that we talked about here:

• This is probably fine
• It sort of feels consistent with the general practice of having things come online in a degraded mode until their deps are available, rather than, say, aborting on startup and requiring human intervention.
• I think this case is different from that general case because: a dependency going offline is an anticipated condition that can always happen and so has to be handled at runtime. Having Nexus come up with an unpopulated database can be avoided altogether.
• Makes me a little uneasy: this change makes some assumptions load-bearing that were previously sort of accidental: that "dbinit.sql" will always set the "version" metadata and that that will always be the last thing that it does. It's not easy to enforce this.
• I think the property we want to check is "the schema matches something that we're capable of operating on". That seems like a much harder problem.
• But as I said above, these are vague fears and if this makes things a lot simpler, it's probably fine. But if we can instead guarantee that the database is populated before we start Nexus, that feels cleaner and more robust.

[davepacheco]

If we keep this: I think we only want the "name" in the primary key.

[smklein]

• I think the property we want to check is "the schema matches something that we're capable of operating on". That seems like a much harder problem.

I think this is potentially another check we should consider - I actually think Nexus validating that the tables-in-CRDB can be parsed might not be a bad idea to do explicitly. But this can be punted when we have more experience with upgrade / schema migrations.

• But as I said above, these are vague fears and if this makes things a lot simpler, it's probably fine. But if we can instead guarantee that the database is populated before we start Nexus, that feels cleaner and more robust.

Yeah, the workaround I'm using in the package-zone branch is to "block on initialize storage before starting services". This is a pattern we'll need to carry forward to the RSS, but should resolve the problem