[zeeshanlakhani]

This is the first of a series of recut PRs split from #675/#696. The validated multicast address types and Vni come from dendrite's dpd-types-versions (oxidecomputer/dendrite#396, stacked through oxidecomputer/dendrite#405). We import the version modules that define them, pinning the rules with the associated version: v14::mcast (validators, unicast sources, is_ssm_address), v8::mcast for the underlay group, and v14::network::Vni.

MRIB route types in mg-api-types-versions are what mg-admin v14 serves. The API version itself is declared in #959 (pt3), and the rest of the split builds on it.

Includes:

• vni is required on route keys, no auto-defaulting to the multicast VNI (77 is OPTE/omicron policy that must be passed in).
• Introduction of our own testing feature (built on dendrite's) with Arbitrary for MulticastAddrV4/V6 and MulticastRouteKey, for upcoming omicron proptests (forwarded through mg-api-types/mg-admin-client in [mcast, pt3] mgd admin API + mgadm for the MRIB #959).
• proptests: address validation specs were moved to dendrite, along with the types. We keep route/key properties here, and execute checks ensuring that our constructors and JSON decoding concur.
• deps: dendrite -> 563cb147 ([softnpu, mcast] wire up the softnpu backend for multicast table ops dendrite#405), softnpu -> a6a87853
• falcon-lab's build.rs now pulls the dpd-client rev out of Cargo.lock and makes it the --dendrite-commit default. Otherwise, npuvm installs dendrite from main, which would supply the wrong types.
• Minor fixin: the rdb/bgp blocks in test-proptest.sh had copied regressions to paths for which the output rule would never match (and skipped that copy on failures). mg-api-types proptests run there now too.

Note: We need to move the dendrite rev back to main when that stack goes in.

[taspelund]

This PR looks pretty good overall. I left some comments, but most of it is around style / API rather than actual functional problems.

One note on the tests: I think it might be good to confirm constructors for SSM types when passing in ASM groups. It's possible they already do this, but I can't recall off the top of my head what range SSM occupies.

I did also ask 🤖 to take a look and these were the noteworthy items it reported:

Minor findings in #943

1. A message points to an API mgd doesn't have. Dendrite's ReservedUnderlaySubnet message ends with "must be created via the internal multicast API". It reaches mgd users word for word, because MulticastGroupError is just an alias for dendrite's error type. Either change the wording in dendrite or accept it.
2. SourceFamilyMismatch can't happen through JSON. Something like {"V4":{"source":"2001:db8::1",…}} fails with a generic invalid IPv4 address syntax. The family-mismatch error only comes from MulticastRouteKey::new(Option, …). The Group variant is also never produced inside this crate; it only exists for ? conversions.
3. A CI line runs no tests, and the PR description is out of date. test-rdb.sh adds -p client-common. But 45466a1 moved client-common's multicast code into dendrite, so the package has no tests now. The "Running client-common unit tests in CI" bullet should go too.
4. Two property tests partly check the function against itself. prop_group_v{4,6}_matches_validator compare MulticastAddrV4::new with validate_external_multicast_ipv4, which is the only thing new calls. The checks that JSON decoding and MulticastAddr agree are the useful part. About 90 lines of generators (GroupV6Case, EmbeddedRpCase) mostly exercise dendrite's validator, which dendrite now tests itself. This only costs maintenance: 1M cases ran in about 100 s.