Allow using a named schema both in JSON and mutlipart payloads

[czechboy0]

Description

The current Twitter OpenAPI doc produces non-compiling Swift code: https://api.twitter.com/2/openapi.json

Error is: Types.swift:22261:84: 'AddOrDeleteRulesRequest' is not a member type of enum 'Generated.Components.Schemas'

The root cause is a limitation in the current multipart implementation in the generator (multipart details: https://swiftpackageindex.com/apple/swift-openapi-generator/1.7.0/documentation/swift-openapi-generator/soar-0009).

Today, the generator assumes that a schema is only ever used either as a JSON payload (and generates it as a Codable type) or as a multipart body, where the top level properties describe the individual parts (in this case the type isn't Codable, can't be because the parts might be binary payloads).

This comes through in the isMultipartContent boolean value in

swift-openapi-generator/Sources/_OpenAPIGeneratorCore/Translator/CommonTranslations/translateSchema.swift

Line 71 in 84b693f

isMultipartContent: Bool = false

Now, this limitation is in place because we assumed that multipart parts are often binary data, and thus aren't compatible with being encoded in JSON.

However, this specific Twitter example does something different: they use the same schema for both JSON and multipart, and the schema itself only uses JSON-compatible types, and never binary data. So technically there isn't a good reason the generator should fail here, but it does, because we didn't expect this to be a common occurrence.

Reproduction

An OpenAPI doc that has a single reusable schema and uses it from two request bodies, one multipart, one JSON.

Package version(s)

swift-openapi-generator 1.7.0

Expected behavior

Either:

1. Relax the checking and allow the reuse as long as none of the top level properties of the schema is a binary payload.
2. Catch this case during code generation and fail with a descriptive error saying that this isn't supported.

However, today the generation succeeds, and the building the code fails. We want to avoid that whenever possible.

Environment

Swift 6.0.3

Additional information

No response

[simonjbeaumont]

Note there's been some movement in the MultipartKit project, which has a new version, heavily inspired by this one.

If resolving this issue starts to involve deep rework in the multipart layer, we should take the opportunity to see if we should replatform on MultipartKit and solve it in one place.

[czechboy0]

This issue is purely in the code generation layer, rather than the runtime layer, so I don't expect this issue to be a driver to move to MultipartKit.

However, I'm still interested in exploring that separately. We'll just need to align it properly, since MultipartKit v5 will require Swift 6.0, so we'll need to wait for that to be our minimum Swift version.