fix(oas3): auto-generate per-variant examples for oneOf/anyOf request bodies (#10765)

[adrianodpdiaz]

Description

Not sure if feat or fix (?)

When a requestBody schema uses oneOf or anyOf and has no explicit examples object, Swagger UI now generates one example per variant and lets you switch between them from the existing Examples dropdown — for both JSON and XML.

• getOneOfExamples() (src/core/plugins/oas3/components/request-body.jsx):
  builds one example per oneOf/anyOf variant, merging shared parent schema keywords into each variant so nothing is lost. Each entry is labeled from the variant's title, x-summary, or $ref name (falling back to oneOf[n]/anyOf[n]). Returns null (no-op) when the media type already declares its own examples, so hand-written examples are never overridden.
• Wired into RequestBody as the source for the Examples dropdown whenever no explicit examples exist.
• XML fix: on first render, the body was built independently of the new per-variant examples and briefly showed <notagname> instead of the actual element name for the first variant. The body now reads directly from the generated example, so the correct root element name shows immediately.

Motivation and Context

Fixes #10765

Reported issue: with a oneOf requestBody schema, Swagger UI only ever generated an example from the first variant, even though every variant is a valid payload. The only workaround was a hand-written examples object, which has to be kept in sync with the schema manually.

How Has This Been Tested?

Manually tested locally (npm run dev) with a spec covering both oneOf and anyOf, each with JSON and XML media types:

• Dropdown lists one entry per variant, correctly labeled.
• Selecting an entry regenerates the body from that variant's schema.
• XML now shows the correct root element on first render (previously <notagname>).
• Media types with an explicit examples object are unaffected.

Example

  ...
    "/orders": {
      "post": {
        ...
        "requestBody": {
          "description": "One of: submit a new order or update an existing order.",
          "required": true,
          "content": {
            "application/json": {
              "schema": {
                "oneOf": [
                  { "$ref": "#/components/schemas/OrderSubmitPayload" },
                  { "$ref": "#/components/schemas/OrderUpdatePayload" }
                ]
              }
            },
            "application/xml": { ...
         ...
    "/shapes": {
      "post": {
        ...
        "requestBody": {
          "description": "Any of: a circle (kind + radius) or a rectangle (kind + width + height).",
          "required": true,
          "content": {
            "application/json": {
              "schema": {
                "anyOf": [
                  {
                    "title": "Circle",
                    "type": "object",
                    "properties": {
                      "kind": { "type": "string", "enum": ["circle"] },
                      "radius": { "type": "number" }
                    },
                    "required": ["kind", "radius"]
                  },
                  {
                    "title": "Rectangle",
                    ...
                  }
                ]
              }
            },
            "application/xml": {
            ...
            }
        }
    }

Screenshots:

Before OneOf	After OneOf

Before AnyOf	After AnyOf

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.