replica_rac2: rm Ready scheduling on piggybacked

[pav-kv]

Since the piggybacked admitted vectors are applied immediately from within the method that clears the queued updates, we no longer need to schedule a Ready cycle. Previously the token release would happen subsequently in Ready handler.

Related to #129508

[cockroach-teamcity]

This change is 

[pav-kv]

@sumeerbhola Alternatively (if, in this flow, Ready scheduling is still necessary for something), let's document why it's needed. Do you know if it's needed? My understanding is that it was only necessary for applying the admitted vector updates.

[pav-kv]

@sumeerbhola Do we need this Ready scheduling so that the token release gets acted on (e.g. send-queue sends some MsgApps)? Or that part is also independent and will notice the token release on its own? E.g. if I understand correctly, AdmitForEval will notice the release without a Ready, but I'm not sure about send-queue.

[sumeerbhola]

With the send-queue we will simply return the tokens, and if there is a send-queue we will already be waiting to be notified when tokens are available. That notification will happen on a separate goroutine, and then we will schedule processing on the raft scheduler (it was called ScheduleControllerEvent in the prototype). So we don't need this ready processing.

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @pav-kv)

[pav-kv]

bors r=sumeerbhola

[craig]

Build succeeded:

• linux_amd64_build
• linux_amd64_fips_build
• local_roachtest_fips
• lint
• windows_build
• examples_orms
• linux_arm64_build
• check_generated_code
• macos_arm64_build
• docker_image_amd64
• unit_tests
• macos_amd64_build
• acceptance
• local_roachtest