Refactor ReflectometryReductionOneAuto polarization correction reduction workflow

[rbauststfc]

When applying polarization corrections using ReflectometryReductionOneAuto, the algorithm first runs through the normal reduction steps, then applies the correction, and finally performs a second run through of ReflectometryReductionOneAuto with relevant parameters altered so that only the steps required for the conversion to Q are repeated.

Polarization corrections basically need to be applied to the lambda (wavelength) workspace before the conversion to Q. The existing approach produces the correct results but has the following drawbacks:

• The conversion to Q that happens in the first run through is a wasted step. The result is overwritten by the conversion to Q that is needed after the corrections have been applied.
• There is a high risk of unintentionally adding steps to the reduction workflow that shouldn't be performed in the second run-through after the polarization correction.
• It is less clear from the history exactly what was done during the reduction.
• There are some steps that are still performed in the second run-through of ReflectometryReductionOne::makeIvsLam, like cropping to wavelength limits, that do not do not have any effect at this stage and so make the workflow less efficient.

The correct workflow for a reduction with polarization corrections would be to:

1) Perform the reduction as usual up to the point where the IvsLam workspaces have been created. 2) Apply the polarization corrections. 3) Perform the conversion to Q - run ReflectometryReductionOne::convertToQ followed by the scale, crop and rebin steps that are performed on the IvsQ workspace to created the final binned workspace at the end of ReflectometryReductionOneAuto.

We should look at how we could best refactor the existing implementation to achieve something that is more efficient and maintainable.

While we're making changes, we should also look at the first step of ReflectometryReductionOne::makeIvsLam that extracts the region of interest from the workspace when summing in lambda. Becky believes that this should be conditional on the background subtraction checkbox rather than processing instructions, as it should only be required if background subtraction is being performed. However the method that holds this logic, ReflectometryWorkflowBase2::makeDetectorWS, isn't just being used in ReflectometryReductionOne so we will need to check properly that this change won't cause issues elsewhere.

See #35855 for further background to this issue.

Technical notes:

• We need to test carefully to ensure that the reduction is still working correctly after the refactor. To help with this, we should review relevant system test coverage and, if not sufficient, amend/add new tests.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had activity in 6 months. It will be closed in 7 days if no further activity occurs. Allowing issues to close as stale helps us filter out issues which can wait for future development time. All issues closed by stale bot act like normal issues; they can be searched for, commented on or reopened at any point. If you'd like a closed stale issue to be considered, feel free to either re-open the issue directly or contact a developer. To extend the lifetime of an issue please comment below, it helps us see that this is still affecting you and you want it fixed in the near-future. Extending the lifetime of an issue may cause the development team to prioritise it over other issues, which may be closed as stale instead.