Add OpenAPI option to use operation input and output schema names - #3182

Can I ask what the need for this is?

One reason why we don't do this is that these OpenAPI structures actually don't match the IO shapes, just the body content. Headers, uri params, and query params are all separate. So if you're trying to map the Smithy structures to the OpenAPI structures, a simple name mapping isn't going to work regardless.

Can I ask what the need for this is?

Thanks for the feedback, @JordonPhillips.

The motivation comes from the original issue #2469 downstream OpenAPI consumers and code generators that use the schema component names as stable identifiers. When the synthesised names are DoSomethingRequestContent / DoSomethingResponseContent, those names carry no direct relationship to the Smithy model's DoSomethingInput / DoSomethingOutput shapes, making traceability harder.

You're right that the OpenAPI body-content schema is not a 1:1 mirror of the Smithy IO shape; headers, URI params, and query params are stripped out. This PR doesn't claim otherwise; the option is purely about naming the synthesised body-content schema after the original IO shape (when there's no collision), not about structural equivalence. The intent is that downstream consumers get a predictable, model-traceable name rather than a generated suffix.

That said, if there's a concern that this naming could mislead consumers into assuming structural equivalence, I'm happy to add explicit documentation/javadoc on the option, warning about this distinction.

Is there an approach you'd recommend instead to surface stable, model-traceable names for the synthesised body schemas? Happy to revise the implementation based on your guidance.