Upstairs should specify the region UUIDs it expects from incoming downstairs connections

[gjcolombo]

See the discussion in #557 for additional context. Upstairs knows how to ensure that a given downstairs's reported UUID doesn't change over time, but there's currently no way to specify expected downstairs UUIDs in a VolumeConstructionRequest, even if they're known to the creator of that request.

This is the snippet that checks for consistency when a downstairs reconnects (and that will need to be amended to check for consistency when a downstairs first connects):

crucible/upstairs/src/lib.rs

Lines 5630 to 5653 in 8cf2566

	/*
	* XXX Eventually we will be provided UUIDs when the upstairs
	* starts, so we can compare those with what we get here.
	*
	* For now, we take whatever connects to us first.
	*/
	let mut ds = self.downstairs.lock().await;
	if let Some(uuid) = ds.ds_uuid.get(&client_id) {
	if *uuid != client_ddef.uuid() {
	panic!(
	"New client:{} uuid:{} does not match existing {}",
	client_id,
	client_ddef.uuid(),
	uuid
	);
	} else {
	info!(
	self.log,
	"Returning client:{} UUID:{} matches", client_id, uuid
	);
	}
	} else {
	ds.ds_uuid.insert(client_id, client_ddef.uuid());
	}

This may require some bolt-tightening around the way client IDs are defined and used. (As things currently stand, up_main creates client IDs such that client_id X corresponds to the Xth element of CrucibleOpts::target; if target were expanded to include expected UUIDs, then it would be possible to prepopulate ds.ds_uuid with the correct ID-to-expected-UUID mappings; but this feels a little bit loosey-goosey, at least to me, and I suspect there's a way to specify all this more formally.)