DEPS: bump across etcd-io/raft#81 and disable conf change validation

[tbg]

We don't want raft to validate conf changes, since that causes issues due to false positives (the check is above raft, but needs to be below raft to always work correctly). We are
taking responsibility for carrying out only valid conf changes, as we always
have.

See also etcd-io/raft#80.

Fixes #105797.
Epic: CRDB-25287
Release note (bug fix): under rare circumstances, a replication change could get
stuck when proposed near lease/leadership changes (and likely under overload),
and the replica circuit breakers could trip. This problem has been addressed.
Note to editors: this time it's really addressed (fingers crossed); a previous
attempt with an identical release note had to be reverted.

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[cockroach-teamcity]

This change is 

[tbg]

bors r=erikgrinaker
🚀

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[blathers-crl]

Encountered an error creating backports. Some common things that can go wrong:

1. The backport branch might have already existed.
2. There was a merge conflict.
3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.

---

error creating merge commit from 404188d to blathers/backport-release-22.2-106515: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 22.2.x failed. See errors above.

---

error creating merge commit from 404188d to blathers/backport-release-23.1-106515: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.x failed. See errors above.

---

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[nvanbenschoten]

@tbg @pav-kv now that we are using DisableConfChangeValidation and we ignore the r.pendingConfIndex > r.raftLog.applied condition here, do we still have a guarantee that a raft leader will never propose a configuration change before it has applied the latest configuration change? In other words, does this change break the Apply and Append invariants from etcd-io/etcd#7625 (comment) for split leaseholder/leader states where the leader is behind on log application? Could that lead to split brain scenarios? cc. @sumeerbhola

[pav-kv]

I had a similar concern when looking at this. I wonder if it would be sufficient to disable only the 2 checks here (which describe the state-machine-level rules for config transitions, which will be also checked by our state machine), but leave the one that @nvanbenschoten linked which is important for raft's config change safety.

Seemingly, re-enabling this one check won't lead to the same perpetual reproposal behaviour for the config change, because the "leader has unapplied config changes" (r.pendingConfIndex > r.raftLog.applied) condition will eventually become false.

[nvanbenschoten]

I wonder if it would be sufficient to disable only the 2 checks here, but leave the one that @nvanbenschoten linked which is important for raft's config change etcd-io/etcd#7625 (comment).

That seems like a reasonable change to me. Do you want to take that @pav-kv?