feat: migrate stfc users service to rest

[William-Edwards-STFC]

Closes UserOfficeProject/issue-tracker#1060

Description

This PR introduces REST changes to the application, replacing SOAP with REST in STFC UserOfficeWebService, and updating relevant configurations and dependencies.

Motivation and Context

The change is required to migrate from the SOAP-based STFC UserOfficeWebService to a REST-based service. This will provide a more modern, efficient, and easy-to-maintain approach to data communication, ultimately improving the performance and reliability of the application.

Please find the mock server pr below.

UserOfficeProject/mock-uows#18

Please find the docker orchestration pr below.

https://github.com/isisbusapps/docker-orchestration/pull/687

Changes

1. Updated .prettierignore, .vscode/launch.json, README.md, apps/backend/.eslintignore, apps/backend/.gitignore, and apps/backend/docker-compose-stfc.e2e.yml files to reflect the migration from SOAP to REST.
2. Introduced the openapi-typescript-codegen package to generate TypeScript/JavaScript client APIs from OpenAPI Specification (OAS).
3. Removed the SOAP client for STFC UserOfficeWebService and replaced it with an auto-generated REST client.

How Has This Been Tested?

Fixes Jira Issue

https://jira.esss.lu.se/browse/

Depends On

Tests included/Docs Updated?

• I have added tests to cover my changes.
• All relevant doc has been updated

[mutambaraf]

Looks good to me but have we resolved adding openapi.yaml to this repo

[ACLay]

I don't see how we could avoid including an api spec or client. We need a client for the code to compile, so we either include that as client code, or the service definition to generate one at build time. I guess it might be possible to have the client as a separate npm package, but the extra infrastructure for that seems excessive compared to just adding an npm command and yaml file here. And it's not like having a client/spec here is new, the old UOWSSoapInterface.ts is generated source code for the SOAP client.

[TCMeldrum]

I agree with alex, I don't see a way around adding the open-api file or the compiled code to this repo without massive hassle to both us and other collaborators. I think I prefer adding the open-api.yaml rather than a folder of regenerated code.

[mutambaraf]

We have more like a month to come up with a package which l think might be a good solution here.

[ACLay]

Sure we've got a month, but what is the problem that having a separate package would address? It'd be adding extra steps to our update process if we need a new client to pull in UOWS updates, and giving us more infrastructure to maintain, so there'd have to be some benefit for that to be worth it, but I don't see what that would be.

[jekabs-karklins]

Approved! But please don't forget to review the two comments I've added, and adjust as you see fit.

I have made the requested changes