Iris: Change Pyris response type

[MichaelOwenDyer]

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• This is a small issue that I tested locally and was confirmed by another developer on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) database calls.
• I followed the coding and design guidelines.
• I added multiple integration tests (Spring) related to the features (with a high test coverage).
• I added pre-authorization annotations according to the guidelines and checked the course groups for all new REST Calls (security).
• I documented the Java code using JavaDoc style.

Client

No client changes

Motivation and Context

Up until now, Pyris and Artemis have been unnecessarily coupled, in that Pyris' responses were always of the type IrisMessage, and Artemis would always deserialize them as such. However, this is an inflexible approach, as it only allows for one single AI-generated variable to be returned per call to Pyris, always the one named "response". This is inflexible. Guidance templates can have an arbitrary number of generations, and it is desirable behavior that you are also able to receive all of these generated values back from Pyris. Therefore I have adapted both Pyris and Artemis to communicate in more general types, while maintaining the current use-case of only having one response.

Note: This change depends on Pyris sending the updated response type as well! This will not work with the current deployment of Pyris.
See corresponding Pyris PR: ls1intum/Pyris#34

Description

• Updated the structure of IrisMessageResponseDTO. Instead of an IrisMessage it now contains a JsonNode content which represents an arbitrary content response from Pyris, for instance a list of JSON objects (which is very possible to generate with a guidance template).
• Added a method in IrisChatSessionService and IrisHestiaSessionService to reconstruct this arbitrary JSON into an IrisMessage for the existing use-case. The method for Hestia is identical, but @Hialus has said this is dead code anyway and will be changed in the future in one of his PRs. For now it is just there for compilation.
• Adapted the test cases correspondingly

Steps for Testing

Prerequisites:

• Pyris must be deployed on the branch of this PR: Development: Add V2 Messages Endpoint Pyris#34
• 1 Student
• 1 Programming Exercise with Iris enabled

1. Log in to Artemis
2. Navigate to the exercise
3. Make sure Iris still responds like normal to your chat input

Review Progress

Performance Review

• I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance
• I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Exam Mode Test

• Test 1
• Test 2

Test Coverage

Screenshots

[Hialus]

Code looks mostly good. I just found one possible edge case that could cause problems.

[Hialus]

Could you maybe mention your findings in the next dev meeting? Especially DTOs should be validated by Jackson, so maybe we can find a better solution, as your way kinda defeats the simpleness of records.