RFC: public methods for Durabler interface in reparentutil

[timvaillancourt]

Feature Description

This RFC discusses a change to the Durabler interface from reparentutil (❤️ this feature) to make it easier to integrate

I feel the private interface method names of the Durabler interface make it hard to write a custom durability policy whose logic is located outside of the reparentutil package

As a direct example, a POC durability policy I am working on is located in a separate repo to our Vitess fork so that it can persist across many Vitess major releases. We build each major release on a new branch from scratch so storing this logic outside makes things a bit cleaner

While the current interface CAN be integrated, to support a Durability Policy that is outside reparentutil, one must:

1. Make all implementation methods in their external package public so that they can be called from reparentutil (eg: PromotionRule vs promotionRule)
2. Make a shim in reparentutil to wrap the public method names with private method names (eg: promotionRule -> myimpl.PromotionRule)
3. Register the wrapped durability policy in func init() using RegisterDurability(...)

This PR illustrates the "shim"/wrapper I am mentioning: slackhq#266

This RFC proposes the interface is changed to this (all public methods):

// Durabler is the interface which is used to get the promotion rules for candidates and the semi sync setup
type Durabler interface {
	// PromotionRule represents the precedence in which we want to tablets to be promoted.
	// The higher the promotion rule of a tablet, the more we want it to be promoted in case of a failover
	PromotionRule(*topodatapb.Tablet) promotionrule.CandidatePromotionRule
	// SemiSyncAckers represents the number of semi-sync ackers required for a given tablet if it were to become the PRIMARY instance
	SemiSyncAckers(*topodatapb.Tablet) int
	// IsReplicaSemiSync returns whether the "replica" should send semi-sync acks if "primary" were to become the PRIMARY instance
	IsReplicaSemiSync(primary, replica *topodatapb.Tablet) bool
}

An interface that allows public method names would allow users to skip wrapping their implementation in private methods, however this would be a major breaking change

In the end, a user in this scenario would still need a "shim" file in the reparentutil package, but it could be as short as:

import "github.com/my/custom/durabilitypolicy"

func init() {
	RegisterDurability("my_durability_policy", func() Durabler {
		return &durabilitypolicy.MyDurabilityPolicy{}
	})
}

Use Case(s)

Users implementing custom durability policies that are located outside of the reparentutil package, which means the methods must be public

[timvaillancourt]

The proposed approach from this RFC is implemented here: #15548. Thoughts appreciated! 🙇

[mattlord]

/cc @GuptaManan100

[GuptaManan100]

I think this is a reasonable change. @deepthi Your thoughts?

[deepthi]

This is reasonable. Probably the initial thought process was that when vtorc was experimental we didn't really want to make the interface public, but now that we've been GA for 4 releases, it makes sense to open up to custom implementations.