Return when VCRs match in target_replace

[jmpesp]

Notifications to Nexus from an Upstairs are best-effort only: they can be missed or dropped, or suffer from all sorts of bad weather. For this reason, Nexus will poll an Upstairs (eg a Pantry attachment or Propolis disk backed by Crucible) to query the state of a repair (especially during region replacement).

For a given VCR replacement request, Propolis will:

• call target_replace(original, replacement)
• update its stored VCR after the replacement has taken place.

The next time that Nexus sends the same VCR replacement request, Propolis will end up calling what amounts to
target_replace(replacement, replacement), and before this commit that would fail with "The VCRs have no difference".

Nexus will poll using with VCR replacement requests, so this commit changes target_replace to return VcrMatches instead of an error. Note that Nexus will not consider this a signal that a replacement has completed.

[jmpesp]

A possible wrinkle:

If Propolis is stuck in starting and the relevant Upstairs (the one where the VCR is being modified) has not activated yet, then Nexus will be able to tell when the repair has finished (after sending the VCR replacement request) with a check to see if the Upstairs activated, but that only works for reconciliation.

If Propolis is running, and the relevant Upstairs is active, then Nexus will not be able to tell when the repair has finished by checking if the Upstairs activated ok (because it was already active to begin with), and after this commit will not be able to track the progress of the live repair using the other variants that would be returned if the arguments didn't change (if the call remained target_replace(original, replacement), the caller would see variants like ReplaceResult::StartedAlready).

This could lead to Nexus attempting to perform multiple target replacements on the same volume because it could believe a replacement is done (read: the live repair has completed) before it is, or it would have to rely on a finished notification, which we've already said is best effort.

[leftwo]

A possible wrinkle:

If Propolis is stuck in starting and the relevant Upstairs (the one where the VCR is being modified) has not activated yet, then Nexus will be able to tell when the repair has finished (after sending the VCR replacement request) with a check to see if the Upstairs activated, but that only works for reconciliation.

If Propolis is running, and the relevant Upstairs is active, then Nexus will not be able to tell when the repair has finished by checking if the Upstairs activated ok (because it was already active to begin with), and after this commit will not be able to track the progress of the live repair using the other variants that would be returned if the arguments didn't change (if the call remained target_replace(original, replacement), the caller would see variants like ReplaceResult::StartedAlready).

This could lead to Nexus attempting to perform multiple target replacements on the same volume because it could believe a replacement is done (read: the live repair has completed) before it is, or it would have to rely on a finished notification, which we've already said is best effort.

In this situation, could crucible tell Nexus "the VCRs match what I have, and there is no repair in progress" Enum type?
I think we have to be very vigilant about replacing downstairs, and being sure we don't replace too many, as that is a path to problems we don't want. This logic here must be rock solid.