invert sled-agent's probe manager

[iliana]

Currently the probe manager in sled-agent periodically asks the Nexus internal API for a list of probes, and also triggers the vpc_route_manager background task if there's a new probe present to ensure the necessary firewall rules are present. These sled-agent --> Nexus requests would not be permitted today, and also introduces latency between the time probes are created/deleted and when they are actually created/deleted by sled-agent.

This logic should be inverted; sled-agent grows an API to accept the current list of probes, which Nexus periodically calls as part of a background task, which is immediately triggered when the list of probes changes. This does not need to be done immediately, but should be done if the probes_get API would otherwise need to change.

It may also be possible to remove the vpc_route_manager background task trigger in sled-agent by instead triggering the background task in Nexus when a probe is created (and removed?).

[bnaecker]

It appears this issue is actually required for #9246, which I'm working on now.

For that issue, we need to modify the shared NetworkInterface type to include information about a possible IPv6 address / subnet that a NIC is on. That's a fundamental type, used in a pretty enormous number of places. One of those is the Nexus internal API, specifically the probes_get() method. The sled-agent uses that to periodically poll Nexus in its ProbeManager. But as this issue indicates, we can't currently rev client-side versioned APIs like the Nexus internal API.