Handle nullability more accurately

[Youssef1313]

My previous PR was trying to handle nullability for enums specifically. This PR is more generalized to handle nulls more correctly as it was still buggy for non-enums.

In addition, the previous fix for enums didn't also fix all enum scenarios. It only fixed it when we are given "oneOf (null, schemaWithEnum)". But if we are given a schema reference instead, we are not going to add "null" to the reference and we will produce the wrong thing.

I'll leave comments on some specific updated tests to explain.

[baywet]

Thanks for the contribution!

[baywet]

Getting closer (I'm only focusing my review on schema object field, and deserialization so far)

[baywet]

To recap our call, and previous discussions

There shouldn't be any field/state for nullability on the OpenAPISchema model, only in the deserialization phases.
We shouldn't be "moving schemas arounds" (except for v2, because that behaviour has been here for 10+ years at this point).

OpenAPI 3.1/3.2

serialization and deserialization should be symmetrical, serialize type null as part of the type property, array or single.

OpenAPI v3.0

serialization

Serialize type null (no other types) as enum null because nullable true by itself is ignored and the resulting schema would validate anything.
Serialize type null + something as type something, nullable true

deserialization

Deserialize type something to something
Deserialized nullable true to a marker in the metadata dictionary.

Once both properties are deserialized:

• if nullable true is by itself, drop it, because it only applies when a type is also provided
• if nullable true is with a type something, add null to the type array

Swagger 2.0

serialization

always serialize type null (with or without something else) as x-nullable: true. That's because :

• one/anyOf is not supported by this version of the standard
• we're already picking the first one/anyOf entry, that bechaviour has been here for a long time, we shouldn't change it
• enum null can't be composed, is therefore useless, so we should diverge from OpenAPI 3.0 behaviour.

Deserialization

Do the same mark and resolve behaviour as V3.0 for consistency, but for the x-nullable extension.

[baywet]

should this also include all of?

[baywet]

use metadata instead of extensions