lib: need to decide how to handle client-side versioning of nexus-client

See the 25 March 2025 control plane huddle, the associated notes, and RFD 532 for more details.

We expect to update the system in such a way that Nexus can assume that sled-agent and Propolis will be updated before Nexus will. (That is, during an update from software release N-1 to release N, the system will install sled-agent/Propolis release N everywhere before beginning to install Nexus bits that rely on the APIs in version N.)

Propolis depends on Nexus APIs exposed through the nexus-client crate. One consequence of this approach to sequencing updates is that Propolis version N must be able to use version N-1 of the Nexus APIs exposed through that crate. In our docs we refer to this as "client-side versioning"--the client may not assume anything (from the structure of the update process) about the API versions that its servers will make available to it, so it must be able to deal at runtime with the absence of a particular API version.

We need to evaluate Propolis's use of nexus-client to see how easy it would be to use client-side versioning correctly. Today it looks like the only consumer of this API is the Crucible backend, which just uses it to notify Nexus that scrubbing has finished and that a read-only parent can accordingly be removed from a volume's Crucible hierarchy. This is a pretty simple notification API, so it may be reasonable to say that it's unlikely to change much, but I'll need to talk to folks with more expertise (cc @jmpesp @leftwo) to make sure I fully understand what's happening here and whether this notification API is likely to change in the future.

Start with RFD 532, the 25 March 2025 control plane huddle notes, and Propolis's use of the nexus-client crate. Focus on the Crucible backend's scrubbing-finished notification and consult the referenced experts about API evolution. Done means determining whether client-side versioning is practical here and recording whether the notification API is likely to change.