Feature Request: allow current/before PRIMARY to be specified in PRS

[timvaillancourt]

Feature Description

This issue proposes that the current/before shard PRIMARY can be specified in PlannedReparentShard (and EmergencyReparentShard 🤔?) RPC requests in order to support a more idempotent(?) operation, where if the provided, "current" PRIMARY is no longer correct, the operation fails or no-ops

This could be implemented by adding an optional request-field CurrentPrimary *topodatapb.TabletAlias containing the alias of who you think the PRIMARY is "now". In ElectNewPrimary the current primary can be compared to this alias and a mismatch is handled

// AvoidPrimary is the alias of the tablet to demote. In other words,
// specifying an AvoidPrimary alias tells the vtctld to promote any replica
// other than this one. A shard whose current primary is not this one is then
// a no-op.
//
// It is an error to set NewPrimary and AvoidPrimary to the same alias.
AvoidPrimary *topodata.TabletAlias protobuf:"bytes,4,opt,name=avoid_primary,json=avoidPrimary,proto3" json:"avoid_primary,omitempty"

The existing AvoidPrimary field sounded like it would do this from the description, but my understanding is it's only used to disqualify a tablet from being the promotion candidate. Please correct me if wrong!

Your feedback is much appreciated!

Use Case(s)

This support can prevent situations when an issue is fixed by VTOrc while external automation is also issuing PlannedReparentShard operations

It would be great if the external automation could say "PRS only if alias X is still the PRIMARY" and if something changed the world in the process, this operation does no go through