Outdated: Issue/1175/improve open api final 2

[tschlat]

This is the final PR for the new OpenAPI feature.

I apologize for the large size of this PR. It includes the following major changes:

1. Updates to the OpenAPI Connector:

• Improved test coverage.
• Replaced validation using "Citrus Control Message" with OAS schema validation based on the Atlassian OpenAPI Validator framework. (This is quite a drastical change and I would appreciate Christophs Feedback on this). I am pretty sure that this is breaking, as the OpenAPI Validator might be stricter than the previous implementation.
• Enhanced random message generation capabilities and test coverage

2. Revised Implementation of TestAPI Generator:

• Now uses the Citrus Builder Pattern.
• Added extensive tests to verify the generated test API against various aspects of OpenAPI.
• Introduced multipartmessage support.
• Included support for all different types of parameter serialization.
• Added an initial implementation of a SOAP Test API generator. While the benefits of this API are somewhat limited, it becomes useful when OpenAPI and SOAP are used together, as both service types can now be handled in a consistent way. Note: the SOAP Test API is in an early stage, with basic functionality and limited testing.
• org.citrusframework.openapi.generator.GeneratedRestApiIT gives an overview on how to use the generated REST API
• org.citrusframework.openapi.generator.GeneratedSoapApiIT same for SOAP although only very little, yet

3. Enhanced Server-Side Header Validation for Parameter Serialization:

• Improved header validation to support arrays of parameters, particularly focusing on different aspects of array-type parameter serialization.
• see org.citrusframework.http.message.HttpQueryParamHeaderValidator for details

[tschlat]

@christophd it really is. I think helps knowing that we have an RC of this in place in production since beginning of 2025. which basically just means that "it works". splitting is difficult, I think. the only think I could think of is separate prs for:

• changes to existing code base
• newly added modules

I tried to avoid breaking the existing OpenAPI feature, but there are some potentially breaking changes:

• I replaced the control message validation with full-fledged schema validation, which may cause issues in existing tests.
• By default, the operation path now considers the OpenAPI base path. This aligns with the behavior of HTTP simulations in the simulator, ensuring consistency.

Additionally, there's a new feature in citrus-simulator that integrates with the OpenAPI feature, enabling scenario generation from OpenAPI specifications. I implemented a huge amount of tests for all this and we have beta-tested the new feature with several inhouse projects. So I am quite confident, that the current state has the required maturity to be moved to main. I spend a couple of hours in the last days for documentation. I am sure, that this would be a good starting point although I am also sure, that Timon has a couple of suggestions for the documentation. If you have any questions or see the need for further documentation, just let me know.

[tschlat]

After discussion with Timon I am rewriting the PR. I will provide smaller PR with specific meanings. So stay tuned before reviewing.

[tschlat]

I took the time to perform a soft reset and carefully organized everything into 21 meaningful commits as the OpenAPI feature evolved. I’m quite confident that the overall result is solid, but individual commits might have minor issues that only resolve fully when everything is merged together.

The first MR is:
#1311

There are 4 further branches named
https://github.com/citrusframework/citrus/tree/issue/1175/oas_2_preparation_for_oas_feature_increase_TS
https://github.com/citrusframework/citrus/tree/issue/1175/oas_3_enhance_validation_and_random_object_generation_TS
https://github.com/citrusframework/citrus/tree/issue/1175/oas_4_implement_OpenAPI_test_api_generator_TS
https://github.com/citrusframework/citrus/tree/issue/1175/oas_5_implement_OpenAPI_test_api_generator_maven_plugin_TS

We will have to merge them one by one as review proceeds.

The last one contains all changes. So we might as well go with that one and review the code on commit level within one MR. It is up to you.