Implement a fall-back solution for when information not available from ICAT

[Anders Markvardsen]

Implement a fall-back solution for when information from ICAT is not available. Currently autoreduction fails if ICAT information cannot be retrieved.

[Lottie Greenwood]

Places ICAT is queried in the front end

[Lottie Greenwood]

Information that will be required from any ICAT replacement:

• Run number
• Instrument name
• RB Number
• Cycle Number
• Location of data file
• When a run ends

Replacing ICAT for the backend is feasible, by using a cron job to watch a certain text file that updates when a run is completed. We can then gain the RunNumber/RB Number by reading the raw file. The cycle number will be assumed to be the current cycle. This is being implemented in #11518

Replacing ICAT for the front end is less simple, given it requires permissions data for each person. This needs to be further looked into.

Currently, in case of ICAT failing, it is suggested a different message telling users to contact ICAT Support rather than autoreduce support is shown.

[Anders Markvardsen]

Concerning cases where ICAT is failing or is giving unexpected results.

1. If an ICAT request fails entirely then ensure we have try/catch for this code and autoreduce continue to run, log this and depending on the case inform user where useful

2. Where ICAT returns unexpected permissions, i.e. the user can only see a subset of the data they think they should see, and ICAT is used for this, we can include in autoreduction help that in such a case they can contact ICAT or user office (we should check who is best to contact for this) to get there permissions changed.