Detect unwriteable Abins cache, raise better error

[ajjackson]

Description of work

Quality-of-life improvement for a common user issue with Abins: in some installations the default user save directory is not writeable.

I am working on a better solution to allow the Abins cache directory to be set more explicitly, but in the hope of getting something that helps users in before the code freeze this should be a good start.

Summary of work

This is related to #38084 ; AbINS users sometimes have an unwriteable default save directory which leads to an unhelpful error message, and need support to fix it. Here we explicitly check that the directory is writeable and raise a more useful error message if not.

Ideally this validation would be part of an explicit input field in the Algorithm and give a nice red asterisk; I'm working on that but it is more involved to test and review. Here is a small fix that provides 50% of the benefits in a small fraction of the case.

To test:

You will need an Abins input file, e.g. ExternalData/Testing/Data/UnitTest/benzene_abins.phonon. Run the Abins algorithm with this VibrationalOrPhononFile and set the appropriate AbInitioProgram (CASTEP for that file) and some name for OutputWorkspace. Other parameters don't matter; run the algorithm and if you have a reasonable user directory set up there should be no error.

Then go to File/Manage User Directories and set the default save directory to somewhere unwriteable like /lib64. Run Abins again (with a different workspace name); it should present a useful error message.

This should work exactly the same for Abins2D

---

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.

[GuiMacielPereira]

Followed the manual test instructions and the behaviour is as expected: when the save directory is unwritable then the error message is printed. The test for checking the directory, directly tries to write to a file under the directory, so it's solid. The error message is clear and informative.