consider a RepairStrategy API for opinionated repairs

while the operator can have a canonical strategy how it would repair the etcd members, according to the etcd maintainers, for later versions users might have opinionated ideas what to do during member failures in the reconciliation loop.

to allow that it might be a good idea to introduce a RepairStratagy or a similar API per etcd Cluster early to allow later for the extension point.

i don't have examples of how the API could look like but one idea would be to define a set of ordered actions and priorities and allow a custom RepairStrategy to adjust the order and priority.

/kind feature
/priority backlog

No files, tests, or concrete entry points are named. Start by tracing the etcd member reconciliation loop and its canonical repair strategy, then determine the API and semantics needed for ordered actions, priorities, and custom strategies. Done would mean a reviewed RepairStrategy extension point with clear behavior, but the issue does not define acceptance criteria.

Written by the indexing model from the issue text.