Switch kin-openapi to libopenapi

[yorickvP]

Required for #1482, #1186, #1216

[yorickvP]

Sadly, libopenapi doesn't discover the invalidness of https://github.com/replicate/cog/blob/main/test-integration/test_integration/fixtures/invalid-int-project/predict.py

[yorickvP]

pb33f/libopenapi-validator#53

[andreasjansson]

I think it's okay to delete that test case. It's a pretty rare case, and wouldn't be hard to upstream a change to libopenapi to handle that case.

[andreasjansson]

@yorickvP could you describe in a bit more depth why we need to switch to libopenapi? It's not obvious to me.

[yorickvP]

This comment contains a summary: #1186 (comment)

We could try to get away with kin-openapi, that would just require fixing the test for the version in #1552

[zeke]

cc @nickstenning who's got a fair bit of experience working with kin-openapi

[nickstenning]

We use kin-openapi in the api repository to process the schemas generated by cog models, and I would probably want to see us using the same code both here and in production.

What is actually wrong with kin-openapi?

[yorickvP]

What is actually wrong with kin-openapi?

No OpenAPI v3.1 support: getkin/kin-openapi#230 (comment)

However, it seems we happen not to use any of the unsupported 3.1 features. Would be good to check somehow.

[nickstenning]

Our own API's spec is 3.1, and we use kin-openapi to validate it in the api codebase. Is the lack of official 3.1 support actually causing us any problems?

[yorickvP]

Here's a list of changes: https://www.openapis.org/blog/2021/02/16/migrating-from-openapi-3-0-to-3-1-0 . My concern here is that these schemas are generated from user input by pedantic, so we don't necessarily control it when they break.
The thing we should mainly test is exclusiveMinimum (pydantic's gte).

[mattt]

Closing in favor of #1687, which rewrites the OpenAPI 3.1 spec version emitted by FastAPI to OpenAPI 3.0.