Replace Talkback proxy with real API server

[dhruvkb]

Problem

The Playwright tests currently use a Talkback proxy to simulate API calls. This is suboptimal and adds a lot of overhead for us to manage the tapes (which are essentially copies of the response the API can very well provide).

Description

Since we have images for the API being compiled inside the CI + CD workflow, we can replace the use of Talkback with the live API server. This will provide the following benefits:

• developing API and frontend features in tandem, without needing to deploy the API, update the tapes and then build the frontend
• making the repository smaller by getting rid of the tapes and the Talkback package
• removing the workflow overhead of running a proxy and updating the tapes

[sarayourfriend]

Just wanted to pop a note in here that this change would make the API and frontend a requirement for each other when developing changes for either. That's fine by me (I don't think segmenting our stack so finely is a long-term benefit, and #4343 will make it less of an issue for contributors), but it's worth noting as a change from the current approach which relies on the live API.

This could also make it harder to realise issues with expected changes in the API to the frontend. The API and frontend do not deploy in tandem, which means either can be ahead/behind what the other's test suite expects, if they are bound together at test-time to always use the latest code. We'd need to be very careful that our configurations match production expectations for the frontend.

[dhruvkb]

We could, in theory, use the latest openverse-api image from GHCR to run as the server for the frontend tests, that would be alike to what responses the frontend would receive if merged and deployed to staging. But then we not be able to work on a cross-stack feature for the API and frontend in parallel because the frontend will always be using a minus-one version of the API in the tests.

[sarayourfriend]

The response data would still need to be populated, and that image wired up to database, es, etc. It can be done in Docker compose, but then I wonder what specifically we're trying to get from testing the API in this way.

If the talkback tapes are tedious to have in the repository, we could keep them in a separate repository that gets cloned when the tests are run, or in a separate squashed branch like we do for GitHub pages.

It does all work with talkback though, so I wonder what the real benefit we're looking for from this would be and if there is a different way to achieve it than overhauling how requests are handled in Playwright context.

If we want to get rid of Talkback, I think Playwright's request interception could do the trick too, but we'd still have to write the responses to disk to cache them and write our own version of tape updating logic.