remake: no --follow-strict-remakes; a strict remake failing says who

A strict remake takes a majority of members whose --strict-keys take
its manifest's signer: no node votes for one without, so
--follow-strict-remakes (1173) goes. A node that doesn't vote still
switches once the others commit, as with any remake.

So that an operator can tell why one fails: a strict remake aborted
for want of a majority (the voting period over, or a majority out of
reach) says in its reason (GET /admin/remakes/{id}, and the
coordinator's log) which members didn't vote, and that a member votes
for one only with its manifest signed by a key of its --strict-keys.
Each of those logs why itself (`Not voting for a strict remake`).

The sim a_strict_remake_too_few_take: only a takes the manifest; the
remake aborts, naming b and c.

1 files changed, 1 insertions, 3 deletions

diff --git a/src/remake/mod.rs b/src/remake/mod.rs
index a075c69..33ac748 100644
--- a/src/remake/mod.rs
+++ b/src/remake/mod.rs
@@ -330,10 +330,8 @@ pub(crate) trait Host: Clone + Send + Sync + 'static {
     /// What a replay does with writes a newer one superseded (`--superseded-writes`).
     fn superseded(&self) -> Superseded;
 
-    /// Whose signature on a strict remake's manifest this node takes (`--strict-keys`),
-    /// and whether it votes for one without any (`--follow-strict-remakes`).
+    /// Whose signature on a strict remake's manifest this node takes (`--strict-keys`).
     fn strict_keys(&self) -> &[crate::access::sshsig::PublicKey];
-    fn follows_strict_remakes(&self) -> bool;
 
     /// Applies a change downloaded from peers (`fetch_change`), then publishes it like
     /// a change received by sync.