kv/raft: force campaigning on leader removal should respect fortification

[nvanbenschoten]

Extracted from #125254.

The remaining use of manual campaigning is in forceCampaignLocked. However, this use is special in that it uses a "forced" campaign through MsgTimeoutNow. It does so because it's trying to handle the case where the raft leader has stepped down or been removed from a range.

In practice, this may be ok today because we will only call forceCampaignLocked as the leaseholder-not-leader. Still, if a leader is fortified, we probably want to handle it a different way. Since we only demote leaders to voters and never remove them immediately, there may be a better way to handle this inside of raft, around this logic:

cockroach/pkg/raft/raft.go

Lines 2176 to 2191 in e243814

	if (pr == nil || r.isLearner) && r.state == StateLeader {
	// This node is leader and was removed or demoted, step down if requested.
	//
	// We prevent demotions at the time writing but hypothetically we handle
	// them the same way as removing the leader.
	//
	// TODO(tbg): ask follower with largest Match to TimeoutNow (to avoid
	// interruption). This might still drop some proposals but it's better than
	// nothing.
	if r.stepDownOnRemoval {
	// NB: Similar to the CheckQuorum step down case, we must remember our
	// prior stint as leader, lest we regress the QSE.
	r.becomeFollower(r.Term, r.lead)
	}
	return cs
	}

Jira issue: CRDB-41715

Epic CRDB-37522