A more targeted approach for V2P mapping orchestration

oxidecomputer/omicron#2536 adds support for Nexus to set OPTE V2P mappings via new endpoints for the sled agent. The approach taken there is a "broadcast" approach: an instance's V2P mapping is broadcast to each sled in the rack. This has the advantage of being correct and not incurring any delete calls.

A more targeted approach would be to see what other instances should have connectivity to an instance (not just share a VPC), see what sleds those instances are allocated to, and only create V2P mappings for those sleds.

For mappings to be correct, a few invariants must hold:

• mappings must be set whenever an instance's sled changes
• an instance's sled must not change while its corresponding mappings are being created

There's additional work with a more targeted approach:

• delete calls would then be required, and this means the ordering of set and delete calls now matters. Note this may also necessitate some sort of generation number / a reliable persistent workflow.
• V2P mappings must be bidirectional in order for an instance's packets to make a round trip, so more work is required to figure out both sides of connectivity and set the appropriate V2P mappings. This isn't a problem with the broadcast approach because one side of the connectivity is taken care of already.

This issue also tracks improving the SQL queries required in Nexus::create_instance_v2p_mappings - as of oxidecomputer/omicron#2536 there are a few separate queries being done where one larger query would do.

Read oxidecomputer/omicron#2536 and the Nexus::create_instance_v2p_mappings entry point first. Define how targeted, bidirectional mappings handle sled changes, ordering, deletion, and persistence, then verify that the SQL work consolidates the separate queries without violating the listed invariants.