SOLR-16924: Refactor requestApplyUpdate step in action=RESTORE

[julia-maimone]

https://issues.apache.org/jira/browse/SOLR-16924

Description

Refactor action=RESTORE to transition UpdateLog to ACTIVE after each replica is restored in RestoreCore call, instead of making calls to RequestApplyUpdate (which effectively transitions UpdateLog to ACTIVE state) on each newly restored replica.
The purpose of this is to simplify and clarify steps of restore. The RequestApplyUpdate op not only buffers updates, it also transitions state (the only part necessary post restoring replica).

Solution

Remove calls to RequestApplyUpdate operation on each newly restored replica, and instead complete transition of UpdateLog to ACTIVE state in each RestoreCore op after data is restored to replica.

Tests

Have run all existing unit tests in solr core module.
This is a refactor, existing tests for Backup/Restore are sufficient.

Checklist

Please review the following and check all that apply:

• [ X] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• [ X] I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
• I have developed this patch against the main branch.
• [ X] I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide

[dsmiley]

Proposed CHANGES.txt:

SOLR-16924: RESTORECORE now sets the UpdateLog to ACTIVE state instead of requiring a separate REQUESTAPPLYUPDATES call in Collection restore. (Julia Lamoine, David Smiley)

A backwards-compatibility issue occurred to me. If during a Solr upgrade, the node issuing this command (the Overseer) is upgraded before the nodes it talks to, then it won't issue REQUESTAPPLYUPDATES. I'll bring this up on the dev list. I think this is fine in a major version upgrade but unsure if it's significant enough in a minor one. It would probably be a transient issue; the restore would fail and ultimately would need to be retried.

[dsmiley]

I'll be pushing this to main with a CHANGES.txt and upgrade note for getting to 10. In 9x I will omit the RestoreCmd part but will add a comment about it disappearing in 10.

[dsmiley]

Going to merge soon. 9x port will exclude the RestoreCmd part so we retain backwards-compatibility for in-place upgrades within the 9x line.

BTW I'm so glad to see Crave working so well -- the GitHub Action in entirety took 8m which is amazing. There is still room for improvement.