Support const values

[czechboy0]

This is important for discriminator values in oneOfs. Coming to OpenAPIKit in the next release.

[czechboy0]

Actually, this is usable in both 3.0 and 3.1. Even JSON Schema explicitly says that const is equivalent to enum with a single value: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00#section-6.1.3

So in 3.0, you do enum: [myValue], in 3.1 you do const: myValue.

[czechboy0]

Note for when we're implementing this: in code, we should generate the hardcoded value, so the compiler knows it at compile time already. But we also need to generate a custom decoder and validate that the value matches the const, as otherwise it shouldn't validate according to JSON Schema.

[simonjbeaumont]

Even JSON Schema explicitly says that const is equivalent to enum with a single value ... So in 3.0, you do enum: [myValue], in 3.1 you do const: myValue.

Note for when we're implementing this: in code, we should generate the hardcoded value, so the compiler knows it at compile time already...

Just to clarify, this doesn't mean we should start emitting a hardcoded value when the OpenAPI document contains an enum with one value, right? For that case, I'd still expect us to emit an enum with one value.

[czechboy0]

I think so, yeah. We already support enums today, and if only one value is documented, the practical use case matches const. But if the const feature is used explicitly, the generated code should skip generating an enum altogether, and emit specific validation code into the decoding initializer.

[czechboy0]

I started investigating this, and this seems to be more work than it's currently worth.

1. A more common way of spelling a constant value is a 1-element enum, which already works today.
2. We could generate a const value as as 1-element enum, but that seems like the ease of implementation driving the API. There should be a first class type for this.
3. We might need to generate the whole thing, which would be a generated struct that wraps a string/int/another constant value and in decoding, would verify the value on the wire matched the expect one, and throw otherwise, and in encoding, it'd always serialize the constant value.
4. I scanned a couple of thousand OpenAPI docs in the wild and found a single occurrence, making this much less used than may other features still in our TODO list.

For these reasons, moving this to post-1.0 towards the end of the list, as it doesn't seem high priority or urgent.