Implement standalone chat detection API for text

[evaline-ju]

Description

As a followup to #195, as an orchestrator developer, I want to implement the changes for the updated API, so that I can provide standalone detections on chat. This endpoint is designed for detectors working on full chat histories

Tasks

1. Implement standalone detector endpoint /text/detection/chat (accepting chat history request) in orchestrator
2. Add http client for detection_chat
3. Test with dummy detector that works on full chat histories

Acceptance Criteria

• Unit tests cover new/changed code
• Examples build against new/changed code
• READMEs are updated
• Type of semantic version change is identified

[mdevino]

The API wasn't very clear o a few things to me, so I'm looking here.

1. Do we need to support deprecated fields (Assistant message's function_call, Function message)?

2. Will we support all modalities for this endpoint? e.g.: For User messages' content array variant, will we support both text and image?

[evaline-ju]

We’re using the openAI messages object directly, so the oneOf with the deprecation will be applied for now https://github.com/openai/openai-openapi/blob/master/openapi.yaml#L9264-L9270

I’m going to answer these backwards since I think it makes more sense

Will we support all modalities for this endpoint? e.g.: For User messages' content array variant, will we support both text and image?

We can start off with this for text particularly [I’ve updated the title of the issue, also the standalone detection endpoint we have now is just /text/chat and the orchestrator standalone endpoint is /text/detection/chat]. If/when we add image modality support in the detectors API, we can consider the image_url and such in mixed or multi-modality support.

Do we need to support deprecated fields (Assistant message's function_call, Function message)?

Because this is pretty much just a passthrough of message history, we can keep any content as is as much as possible. Note that this endpoint is meant firstly for detectors that take whole chat history, and not processing individual content messages with detectors.

[gkumbhat]

@mdevino the standalone API is mainly targeted to support chat as the input. It doesn't necessarily have to be processed by a chat completion model implementing open-ai API etc. So, parameter wise, we don't need to worry about any of those parameters. If such parameters are supported by the underlying model, then we would basically do a passthrough, as @evaline-ju mentioned.

We decided to use "messages" format more closely to open-ai to make it easier for users to pass their already formatted data.