Report underlying processor arch on Arm Macs

If someone with an Arm chip is running an x86_64 Mantid (currently the only type we make for MacOS), then it will run under the Rosetta translation layer. This means the OS architecture will be reported as x86_64. This bit of code is how Apple recommends to check if your code is running on Rosetta, which will then allow us to correctly determine how many Arm Mac users we have.

See here for the Apple docs. The example is in Objective-C but it's pretty similar in this case to C++.

Fixes #37592

Description of work

If running on an Apple machine, and the OS architecture is given as x86_64, then check if the code is running on Rosetta. If it is then change the osArch entry in the usage report to arm64_(x86_64). A native app will say the architecture is arm64 so I think it would be useful to distinguish between the two cases later (when we have a native version).

To test:

We don't want to actually send any usage reports, so e.g. comment out line 332 of UsageService.cpp

status = helper.sendRequest(url, responseStream);

Turn on usage reporting, put a breakpoint somewhere where you can see which OS architecture is going to get put into the osArch field of the usage report, e.g. in ConfigService.cpp::1013 getOSArchitecture. If you have an Arm Mac running a native build, then you should get arm64. If you have an Arm Mac and are running under Rosetta (you'll need a package build for this) then the string should be arm64_(x86_64). If you have an Intel Mac then it should be x86_64.

I think you can also check the OS string by running SegFault and checking the error report (usage reporting must be on still).

This does not require release notes because this does not change any user-facing behaviour.

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.

mantidproject / mantid