feat: [Orchestration] Support for Orchestration config persistence

[Jonas-Isr]

Context

• https://github.com/orgs/SAP/projects/62/views/7?pane=issue&itemId=138596334&issue=SAP%7Cai-sdk-java-backlog%7C343

The PR enables the management of Orchestration Configs in prompt registry (create, delete, list via generated code and new client) as well as convenience to use these Orchestration Configs in the OrchestrationClient.

Sample of new convenience:

// create OrchestrationPrompt (for placeholder values and history) with already existing convenience
List<Message> history = List.of(new SystemMessage("System Message"));
OrchestrationPrompt prompt = new OrchestrationPrompt(Map.of("placeholder", "value")).messageHistory(history);

// create (newly added) OrchestrationConfigReference to refer to saved Orchestration config
OrchestrationConfigReference reference =
    OrchestrationConfigReference.fromScenario("scenario").name("name").version("0.0.1");

// use OrchestrationClient todo chat completion with the referenced config
OrchestrationChatResponse response = client.executeRequestFromReference(prompt, reference);

Feature scope:

• add new OchestrationConfigClient in prompt registry
  • unit and e2e tests for generated code and new client in prompt registry
• convenience for use with OrchestrationClient
  • unit and e2e tests for new convenience

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Aligned changes with the JavaScript SDK
• Documentation updated
• Release notes updated

[Jonas-Isr]

This could also throw instead of just logging. Was not sure which is better.

[Jonas-Isr]

We could add

public OrchestrationChatResponse executeRequestFromReference(
      @Nonnull final OrchestrationConfigReference reference) {...}

as well for even more convenience? (The prompt is used to forward placeholder values and the message history, so it is not always needed but probably in most actual use cases).

[newtork]

I'm not a fan of either method option. Also not liking existing executeRequest siblings.

To me this method looks similar to "normal" use-case

public OrchestrationChatResponse chatCompletion(
@Nonnull final OrchestrationPrompt prompt, @Nonnull final OrchestrationModuleConfig config)

As a user i would assume methods have similar signature whether they use an explicit orchestration config, or an implicit config.

Or is the semantic usage different (enough) to justify a different name schema?

[Jonas-Isr]

I decided against making this a sealed interface plus two permitted classes because I felt that would be a bit of an overkill for such little logic. Would be interested in your thoughts about that.

[newtork]

(Major/Discussion)

I don't think we want to extend a custom class from generated code. Did we do that before? Is there no other way to apply mixins? Otherwise this has a code smell; we're introducing hand-written public API code for the sake of a workaround.

[newtork]

(Minor)

You could've turned this into a currying builder, when the classes were interfaces.

return (name) -> (version) -> new OrchestrationConfigReference(null, scenario, name, version);

[newtork]

(Minor)

We could reduce future maintenance if the getters were package scoped(?)