revert: auto-set nullable for Kotlin nullable types (#3256)

[thejeff77]

Summary

Reverts #3256. The KotlinNullablePropertyCustomizer auto-marks Kotlin T? as nullable with no per-property opt-out, which silently produces incorrect specs for backends using @JsonInclude(NON_NULL). This restores pre-#3256 behavior pending an upstream NullableMode proposal in swagger-core.

Why revert rather than patch

The customizer auto-marks any Kotlin T? property as nullable in the generated schema. This is correct only when Jackson actually serializes null values onto the wire — i.e., default Jackson configuration. For backends that use @JsonInclude(NON_NULL) (a widespread Jackson convention) the resulting spec is wrong: it claims null can appear when in fact Jackson strips null fields entirely.

The natural per-property override would be @Schema(nullable = false). This cannot be honored. @Schema.nullable() is a boolean defaulting to false, which means via reflection there is no way to distinguish "user explicitly wrote nullable = false" from "user never specified anything." This is a known design wart on @Schema's legacy boolean fields — the same issue swagger-core addressed for required by introducing RequiredMode in 2022 (swagger-api/swagger-core#4221, swagger-api/swagger-core#4286, commit b1729fcf1) and for readOnly/writeOnly by introducing AccessMode in 2018 (swagger-api/swagger-core#2675, swagger-api/swagger-core#2677). No equivalent NullableMode exists yet.

Without that override, this PR's auto-detection cannot be made correct for the population it impacts. A global enable/disable flag (proposed in #3269) addresses the symptom but not the underlying override gap — codebases that mix @JsonInclude(NON_NULL) and default-Jackson DTOs still have no clean answer, and shipping the flag adds global config surface for a problem that will be solved per-property upstream once NullableMode exists.

Path forward

1. This revert — restores pre-feat: auto-set nullable: true for Kotlin nullable types in schema properties #3256 behavior. Users in the original Support for auto conversion of Kotlin nullable type to schema: { nullable: true } #906 cohort fall back to the explicit @field:Schema(nullable = true) annotation, the long-standing workaround they were using before feat: auto-set nullable: true for Kotlin nullable types in schema properties #3256.
2. Swagger-core proposal for NullableMode { AUTO, NULLABLE, NOT_NULLABLE } mirroring RequiredMode. Issue/PR to be opened on swagger-api/swagger-core. This benefits both layers — the swagger-core @Nullable auto-detection added in 5001: Add support for @Nullable annotations in OpenAPI 3.1 schemas swagger-api/swagger-core#5018 (2025-11) hits the same override gap and would also use the new mode.
3. Re-introduce KotlinNullablePropertyCustomizer once NullableMode ships upstream, with the customizer honoring NullableMode.NOT_NULLABLE as an explicit per-property override and NullableMode.AUTO (default) as the auto-detection trigger.

Background discussions

• Original feature request: Support for auto conversion of Kotlin nullable type to schema: { nullable: true } #906 (first raised 2020, closed)
• User reports of breakage: comments on feat: auto-set nullable: true for Kotlin nullable types in schema properties #3256 from @Majstr, @0xabadea, @fatso83, @rupert-jung-mw
• Proposed flag-based workaround: Add mechanism to disable nullable for Kotlin properties #3269 (close in favor of this revert)
• Related swagger-core nullable work: 5001: Add support for @Nullable annotations in OpenAPI 3.1 schemas swagger-api/swagger-core#5018 (native @Nullable support), [Bug]: Issues using @Nullable annotations in OpenAPI 3.1 schemata swagger-api/swagger-core#5077, [Bug]: Wrong schema for nullable object swagger-api/swagger-core#5158, fix: ensure that @Nullable does not incorrectly affect object schemas swagger-api/swagger-core#5124

Test plan

• CI passes (the revert deletes the customizer and its tests; no new tests required)
• Manual confirm: a Kotlin data class with val foo: String? = null no longer auto-marks as nullable: true (back to pre-feat: auto-set nullable: true for Kotlin nullable types in schema properties #3256 behavior)
• Manual confirm: existing @field:Schema(nullable = true) opt-in still works

Risk

Low. This is a literal git revert of the merge commit; no manual conflict resolution. Users relying on the auto-detection lose it and must re-add @field:Schema(nullable = true) until the upstream NullableMode work lands.

[thejeff77]

Cross-link: the upstream NullableMode proposal referenced in the path-forward section is now open at swagger-api/swagger-core#5160.

[thejeff77]

Note on CI: the failing `Java CI with Maven` check (`Non-resolvable parent POM for org.springdoc:springdoc-openapi-tests`) is pre-existing infrastructure, not caused by this revert. Same exact failure on:

• the previous merge to `main` (run 24686358254, 2026-04-20)
• run 24317160951 (2026-04-12, on the 3.0.3 line)
• multiple intermediate `action_required` runs

This PR is a literal `git revert -m 1` of the #3256 merge commit — no manual conflict resolution, no test changes beyond the original PR's tests being deleted alongside the customizer they covered. The same code (pre-#3256) was passing CI before #3256 was introduced.