Stop ReflectometryReductionOneLiveData from re-writing the spectra map on instrument load

[rbauststfc]

Description of work

Summary of work

Changes the step in ReflectometryReductionOneLiveData that loads the instrument so that it doesn't re-write the spectra map, as this can result in spectra being associated with the wrong detectors.

Fixes #38202.

Further detail of work

The live data workspace already has the instrument loaded, but we need to re-load it because many of the Reflectometry IDFs position their pixels based on the theta value in the log. We add this theta value as part of setting up the workspace in ReflectometryReductionOneLiveData, so we then re-load the instrument to apply the changes. Re-writing the spectra map under these circumstances can lead to spectra being associated with the wrong detector pixels. This PR fixes that issue.

There were a few updates/additions required for the unit tests, and I've also refactored the tests in a couple of places to avoid code duplication.

To test:

1. To prevent the algorithm attempting to look up information from the instrument, edit the code in method _live_value_list, to provide values for _theta_name, _s1vg_name and _s2vg_name:

self._theta_name(): LiveValue(2.3, "deg", self._alternative_theta_name(), LiveValue.LOG_TYPE_NUM_SERIES),
self._s1vg_name(): LiveValue(1.0, "m", self._alternative_s1vg_name(), LiveValue.LOG_TYPE_NUM_SERIES),
self._s2vg_name(): LiveValue(3.0, "m", self._alternative_s2vg_name(), LiveValue.LOG_TYPE_NUM_SERIES),

2. Run the following script:

in_ws = LoadNexus("SURF138942")
out_ws = ReflectometryReductionOneLiveData(InputWorkspace=in_ws, Instrument="SURF")

It should complete successfully. If you check the detector table on in_ws (i.e. using Show Detector from the right click menu) then you should see detectors 20001, 20002, 30001 listed.

---

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[github-actions]

👋 Hi, @rbauststfc,

Conflicts have been detected against the base branch. Please rebase your branch against the base branch.

[adriazalvarez]

Tested it off cycle. It doesn't throw any error and expected detectors look correct.
Thanks for improving the tests.
Needs to resolve a conflict as ruff checks have been added recently. I'll wait until it is rebased to approve.

[adriazalvarez]

Thanks for rebasing it.