Stop adding messages to backend history via frontend 🛠🛠

[pmarsh-scottlogic]

I note that there is an endpoint to add a message to the backend's chat history. We only every do this as a direct result of something that happened in the backend. Therefore this endpoint and all its associated network calls don't need to exist.

🔧 Remove the endpoint /openai/addHistory and add messages to history in the backend instead. Delete the frontend methods that use this endpoint, including addInfoMessageToChatHistory, addResetMessage, addInfoMessage, and other methods tat only exist to add stuff to backend history.

The user actions that would result in a change in chat history and thus a superfluous API call are:

• level reset handled in Streamline network calls for resetting level progress 🛠🛠 #645
• winning a level 828 steamline win level info message #873
• defence triggered
• defence alerted
• update defence config 828 streamline configure defence info message network call #874
• toggle defence 828 streamline network call for toggle defence #884
• change chat model 828 streamline change chat model request #883
• configure chat model 828 streamline chat model configuration info message network call #875

ACCEPTANCE CRITERIA

The following acceptance criteria boil down to doing the above listed actions, checking that the actions work and the info messages are added, and there is only one network call

WHEN user wins a level
THEN level completion message appears as normal in chat
AND only one network call of type fetch

WHEN user sends a message that triggers a defence (e.g. configure character limit to be super small, then send a long message)
THEN the defence triggered message appears as normal in chat
AND only one network call of type fetch

WHEN user sends a message that alerts a defence (e.g. configure a character limit to be small, then disable the defence again and send a long message)
THEN the defence alerted message appears as normal in chat
AND only one network call of type fetch

WHEN user configures a defence (i.e. changes the character limit)
THEN the defence configured message appears as normal in chat
AND only one network call of type fetch

WHEN user toggles a defence on or off
THEN the defence enabled / disabled message appears as normal in chat
AND only one network call of type fetch

WHEN user changes the chat model (under model configuration)
THEN the model changed message appears as normal in chat
AND only one network call of type fetch

WHEN user changes a configuration of the chat model (under model configuration)
THEN the model configured message appears as normal in chat
AND only one network call of type fetch

---

Here's how you quickly find out what api calls are being made that are fetch type. Note that the CombinedFonts call is of type xhr, therefore we ignore it.

[chriswilty]

Three usages remaining:

• MainComponent, when a defence was reset by the user
• ChatBox, when a defence was triggered or alerted during a chat

Once these have been tackled, the service call can be removed from frontend and backend code.