Fix filters for probe v2p mappings

[internet-diglett]

During the changes made in #5917, we accidentally filtered for instances when querying for probe v2p mappings. This PR fixes that filter, and also updates the v2p mapping RPW to use the SledFilter::V2PMapping enum.

[FelixMcFelix]

I've basically cribbed the same logic from this block to select the sleds we talk to in the VPC route background task:

omicron/nexus/src/app/background/tasks/vpc_routes.rs

Lines 60 to 88 in 97fe552

	let sleds = match self
	.datastore
	.sled_list_all_batched(opctx, SledFilter::InService)
	.await
	{
	Ok(v) => v,
	Err(e) => {
	let msg = format!("failed to enumerate sleds: {:#}", e);
	error!(&log, "{msg}");
	return json!({"error": msg});
	}
	}
	.into_iter()
	.filter(|sled| {
	matches!(sled.state(), SledState::Active)
	&& matches!(sled.policy(), SledPolicy::InService { .. })
	});
	// Map sled db records to sled-agent clients
	let sled_clients: Vec<(Sled, sled_agent_client::Client)> = sleds
	.map(|sled| {
	let client = sled_client_from_address(
	sled.id(),
	sled.address(),
	&log,
	);
	(sled, client)
	})
	.collect();

Is this fix something we should apply there, too?

[internet-diglett]

It could cause issues if we want these sleds to receive updates / be managed even after they are marked as non_provisionable, as in this issue:
#5872

Does that scenario apply here?

[FelixMcFelix]

I think it does; my understanding of 'non-provisionable' is that we're not placing new instances on such a sled, but existing ones should still function as intended? In that case we should be making sure that those sleds have up-to-date routing tables for their instances' OPTE ports while they still exist.

[internet-diglett]

Ok, so maybe we need to rename it from SledFilter::V2PMapping to SledFilter::VpcConfig or similar and apply it to both RPWs?

[FelixMcFelix]

I think that would work!

[jgallagher]

I'd like to make this less error-prone! The docs on SledFilter have this note:

/// The meaning of a particular filter should not be overloaded -- each time a
/// new use case wants to make a decision based on the zone disposition, a new
/// variant should be added to this enum.

but I imagine it's easy to miss and InService seems general to a fault, given that guidance. I'm inclined to try removing the InService variant altogether and updating all its users with more specific variant names, but am open to other suggestions!

[jgallagher]

Also FWIW, I believe SledFilter::InService actually does do the right thing here - it includes sleds that are not provisionable. #5872 was caused by the raw DB query inspecting the sled policy/state columns directly and not going through the SledFilter machinery at all. That said, I stand by the previous point that I think InService is still too general and will still try the renaming exercise.

[FelixMcFelix]

Looks good, thank you!