raft: ensure leadMaxSupported cannot regress when a leader bumps its term

[arulajmani]

Describe the problem

While staring at some raft code with @nvanbenschoten earlier today, as one does, we re-discovered this TODO:

cockroach/pkg/raft/raft.go

Lines 1353 to 1356 in 77b210b

	// TODO(arul): add special handling for the r.lead == r.id case with an
	// assertion to ensure the LeaderSupportExpiration is in the past before
	// campaigning.
	if r.supportingFortifiedLeader() && r.lead != r.id {

As written, it's possible for a raft leader to regress leadMaxSupported after it steps down, if it calls an election, doesn't win it, but de-fortifies followers and allowing another follower to win an election. This is possible because the TODO isn't addressed and this logic in inFortifyLease:

cockroach/pkg/raft/raft.go

Lines 1480 to 1486 in 77b210b

	inFortifyLease := r.supportingFortifiedLeader() &&
	// NB: A fortified leader is allowed to bump its term. It'll need to
	// re-fortify once if it gets elected at the higher term though, so the
	// leader must take care to not regress its supported expiration.
	// However, at the follower, we grant the fortified leader our vote at
	// the higher term.
	r.lead != m.From &&

---

To fix this, we could either:

1. Address the TODO and ensure leadMaxSupported is in the past by calling CanDefortify in hup.
2. OR remove the special case handling in inFortifyLease and check supportingFortifedLeader without exception in hup.

We settled on approach 2, as we no longer need this implicit de-fortification now that we have the explicit MsgDeFortifyLeader flow.

Jira issue: CRDB-43740

Epic CRDB-37522