kv: conditionally handleReady after tick

[nvanbenschoten]

Related to #133885.
Related to #133216.

This commit adjusts Replica.tick to check RawNode.HasReady when deciding whether a Ready struct should be processed (Replica.handleRaftReady) from the ticked replica. Previously, we would unconditionally pass through Replica.handleRaftReady after a tick, even if doing so was unnecessary and we knew ahead of time that we would hit this early return:

cockroach/pkg/kv/kvserver/replica_raft.go

Line 1025 in 57aab73

if !hasReady {

This was mostly harmless in the past with quiescence and a cheap short-circuit in handleRaftReady, but has become more problematic recently for the following three reasons:

1. Leader leases don't permit quiescence. We have some work planned to allow follower replicas to quiesce under a leader lease (see kv: local, StoreLiveness-based quiescence for Leader leases #133885), but even after that work, we likely won't allow quiescence for the leaseholder. This means that
2. Replica.handleRaftReady has been getting more expensive, even in the no-op case. This is because of work done in Replica.updateProposalQuotaRaftMuLocked and work done for replica admission control v2 (RACv2).
3. At some point in the future, we would like to revert 5e6698 and drop the raft tick interval back down to something like 200ms. This will allow us to address raft: separate out ElectionJitterTicks from ElectionTick #133576 and further reduce failover times.

Release note: None

[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