openapi3: ensure YAML marshalling matches JSON's

[damien-talos]

I noticed that some types used MarshalYAML as the source of truth for MarshalJSON, but others didn't.
Some of those were out of sync, especially with regards to the serialization of extensions.

This PR updates all the MarshalJSON functions to call the MarshalYAML one, with the result that both JSON and YAML marshalling should result in the same value being written.

[fenollp]

Hi! Thanks for submitting this. Should we be thinking of a regression test?
Please rebase your PR, otherwise LGTM :)

[damien-talos]

@fenollp Certainly, I'll rebase my PR.
I'm happy to add tests, though I'm not sure what that would look like?
Perhaps somehow generating tests that serialize various objects to both JSON and YAML, than de-serialize them, and compare them to ensure they are equivalent? Is there existing code to generate tests like that, or would they have to be hand-coded?

[fenollp]

Such tests already exist, I was just wondering if you'd thought of something new. No worries, let's just rebase :)

[damien-talos]

I did a rebase here, and fixed a few issues, but I've now got tests that are failing because the properties are serialized in a different order.
How important is the order of the properties in the serialized output? I could update the snapshots to reflect the new order (which seems to be alphabetical), but I'm not sure if that's desired or not?

[fenollp]

I believe you forgot to push your rebase?

On keys ordering: theoretically order doesn't matter. Now, we have users requesting certain orderings: "as written", "alphabetical" and custom.
Could you show which tests now fail due to ordering / rebase this PR?
Note you can use JSONEq.

[damien-talos]

I believe you forgot to push your rebase?

On keys ordering: theoretically order doesn't matter. Now, we have users requesting certain orderings: "as written", "alphabetical" and custom. Could you show which tests now fail due to ordering / rebase this PR? Note you can use JSONEq.

There's quite a number of tests that are failing due to these changes.
I've got some work-in-progress locally to resolve these, by simply updating the snapshots, but I've also done some work to use an ordered map for the serialization, to give full control over the serialization / deserialization everywhere. The only downside to that is that if I replace the existing maps with the ordered map (e.g. for properties, additional properties, extensions, etc.) that breaks the existing api (I've been using go-ordered-map for this).

If this is something that interests you, I can continue on with that work in a separate PR, to at least provide a foundation / exploration of how that ordered marshalling / unmarshalling might look.

[fenollp]

Cool! I have one myself you can pull from if you'd like: #695

But hm I'll try to merge this one first. Maybe for now we can just sort the fields, so that only YAML marshaling sees ordering changes. Did I get that right?
I'll dive deeper some time at the end of the week hopefully

[damien-talos]

Okay, sorry for all the pushes, but I think I've fixed the tests and the PR build checks now.

[fenollp]

Thanks for this!