feat: map kotlinx-datetime classes to date-time

[schott12521]

This is to address what I brought up here: #46

The only issue I foresee is with LocalDateTime as it doesn't include a timezone by default 🤷

I've added tests that verify the generated output matches this:

{
  "openapi" : "3.1.0",
  "info" : {
    "title" : "Open API Specification",
    "description" : "test",
    "version" : "1.0.0"
  },
  "paths" : {
    "/temp" : {
      "get" : {
        "responses" : {
          "200" : {
            "description" : "Success",
            "content" : {
              "application/json" : {
                "schema" : {
                  "$ref" : "#/components/schemas/sources.Response"
                }
              }
            }
          }
        }
      }
    }
  },
  "components" : {
    "schemas" : {
      "sources.Response" : {
        "type" : "object",
        "properties" : {
          "message" : {
            "type" : "string",
            "format" : "date-time"
          }
        },
        "required" : [ "message" ]
      }
    }
  }
}

So that we don't include unnecessary kotlinx-datetime stuff in our openapi specs 😄

[tabilzad]

A couple of things to think about.

• Kotlin data related serializers are configured to produce a general ISO-8601 while the OpenAPI date-time spec assumes RFC-3339 which is a specific subset of ISO-8601. https://ijmacd.github.io/rfc3339-iso8601.
• Support for custom serializers
  • KtorFieldDescription annotation already allows to override or set the format explicitly, so in case the, now default, behavior of using date-time is not desired - it can be overridden. But we should probably think if it'd be helpful to override the default globally instead of annotating every property.

[tabilzad]

Instead of comparing simple names, we should compare fully qualified package path with the name. So let's define the corresponding fq names in ClassIds.kt similar to others. Then we could just compare kotlinType.classId

[tabilzad]

also we're adding this explicit check here for when the whole response body in just an instant or date but the same case for request body is not handled.

[schott12521]

Ahh I can add a test that validates request body works the same as well, good call.

[tabilzad]

Same for all of the above, re: use classId's

[tabilzad]

also you could probably re-use this method in the resolveToOpenSpecFormat for consistency.

[tabilzad]

There is also java.time.LocalDateTime

[schott12521]

I think there should actually be seperate mappings, but im not sure what the specs map to.. anyway LocalDate is a date object, and Instant is a datetime object, which are both strings with different string formats per the spec: https://swagger.io/docs/specification/v3_0/data-models/data-types/#strings