[Discussion][cpp-boost-beast-client] OAS 3.1 validation and SSE generator options

[bold84]

Is your feature request related to a problem? Please describe.

PR #24760 adds compile-time-validating C++ output for OpenAPI 3.1 schemas and typed handling for text/event-stream. These features require policy choices that are not safely expressible through custom Mustache templates alone because they affect generator-side schema lowering, generated runtime behavior, and API return types.

Per the contribution guidelines, this issue requests feedback on three proposed cpp-boost-beast-client generator options before they are merged.

Describe the solution you'd like

compileWithValidation

Boolean, proposed default: true.

• true: generated model decoding enforces oneOf exactly-one, anyOf at-least-one, and discriminator branch validation.
• false: compiles out those branch checks for high-throughput clients. Representation-safety checks such as numeric convertibility, integer range, and required properties remain active.

The proposed default favors schema correctness. The tradeoff is additional generated code, compile time, and decode-time work. Feedback requested: should validation be enabled by default, opt-in, or unconditional?

formatAssertionPolicy

Enum, proposed/default and currently supported value: annotation.

OpenAPI 3.1 inherits JSON Schema 2020-12 behavior in which format is annotation-only unless an assertion vocabulary is explicitly enabled. The generator therefore keeps format metadata out of composition branch-match counts and rejects unsupported policy values rather than silently changing validation semantics.

Feedback requested: should this explicit fail-closed option be exposed now, or should the generator use fixed annotation behavior until a strict assertion implementation exists?

sseSchemaMode

Enum, proposed default: representation.

• representation: a text/event-stream response schema describes the media representation; generated APIs return one raw data string per framed event.
• jsonEventData: the schema describes each event's JSON data payload; each payload is decoded and validated against that schema.
• A per-operation x-sse-event-data-schema extension provides local opt-in to the second behavior.

Feedback requested: is a global mode plus per-operation override appropriate, or should typed event-data interpretation be vendor-extension-only?

Describe alternatives you've considered

• Keep all three behaviors fixed and expose no generator options.
• Make schema validation opt-in to preserve smaller/faster generated clients by default.
• Defer formatAssertionPolicy until more than one behavior is implemented.
• Use only x-sse-event-data-schema rather than a global SSE option.
• Use custom templates. This cannot fully implement these choices because the schema IR and response model are assembled in Java before template rendering.

Additional context

Implementation and detailed compatibility notes are in #24760. The PR includes focused Java tests, native C++ compile/runtime tests, generated sample updates, and JSON Schema Test Suite coverage.