[zeeshanlakhani]

This adds a swadm multicast subcommand (aliased as mcast as well) for inspecting, creating, and deleting the multicast groups programmed on the switch:

• multicast list [-t <tag>] [-k external|underlay] renders all groups as a
  table view, filtered by tag, by replication kind, or both.
• multicast get <group-ip> shows one group's full configuration.
• multicast add <ext-ip> -i <underlay> -m <mac> -v <vni> [--member port/link:dir]... [--vlan <id>] [-s <src>]... [-t <tag>] creates an external group and the underlay group that it maps to.
• multicast del <group-ip> [-t <tag>] [--underlay-only] deletes the pair, or just an unreferenced underlay group with --underlay-only.

The kind filter matches on the response type: external means an external multicast group with a NAT target and no (underlying) direction membership; underlay groups reside in the reserved ff04::/64 subnet and replicate to the member ports (to guest subscribers).

add/del subcommands work together as a pair (of groups) by default: add creates the underlay group, then the external group that maps to it (1:1, rolling the underlay back out if the external create fails), and del checks both (shared) tags before removing either group. The -t flag defaults to the client tag on both subcommands, similar to arp add. del --underlay-only removes unreferenced underlay groups, including any left behind after a failed pair deletion.

Includes:

• multicast get runs through TabWriter, like list; list headers use Title Casing, like nat/attached.
• add flags match what nat add has, i.e. -i underlay, -m mac, -v vni, and --member is long-only.
• clap parses right into the new types from [dpd,dpd-api,dpd-types] make external multicast constraints self-enforcing #396 (type-validation), with bad addresses failing at arg parse-time.
• tests moved onto the common expectorate setup from Regression tests for swadm #350 (per Cory's review), seeded through swadm itself, which removes the tests' need for tokio and the dropshot client.

[cfzimmerman]

swadm now has common infra for tests. Can we move this module over to the new expectorate pattern?

#350

[cfzimmerman]

In my understanding, this test uses the dropshot client to create/delete multicast assets so that we can then inspect the output using swadm. Doing so requires the updated tokio dependency.

First, I'd like to use the shared expectorate infra for swadm validation as stated above.

Taking it further, can we add multicast asset creation/deletion to swadm so that this test doesn't need the dropshot client at all?

Doing so creeps the scope of this PR, and restricting to dropshot makes sense if you know of a reason swadm definitely should not support multicast creation/deletion. But adding that to swadm sounds like useful functionality and would simplify this test.

Simplifying swadm tests isn't an end goal in itself, but swadm tests are close enough to human/hand testing that I want to be thoughtful. For example, could you then set up a multicast demo just using cli commands? That would be pretty cool.

[cfzimmerman]

Btw the "request changes" is for you to please check out the new expectorate test structure. Which was merged since you opened this PR, so apologies for the churn!
Adding create/delete and using tabwriter in multicast_get are your decision.

[cfzimmerman]

Wow this totally rocks. Tysm for updates after the last review. Awesome functionality and well tested.

[cfzimmerman]

👍