Connexion: Replace custom json reference resolver with off-the-shelf one

[dtkav]

Some of the code for resolving references if fairly custom, and kind of nasty (esp. in #621 the openapi3 branch)
I wanted to float the idea of using something like https://github.com/gazpachoking/jsonref
It will lazily resolve the references as they are used.

I'm happy to put up a demo - let me know what you think.

[rafaelcaricio]

I think this is a great suggestion. We should be try to use ready components to put together Connexion features and bring in maintainable pieces together. This improves community engagement, cleaner design, and _less code to maintain_ (yay!).

[jmcs]

I also agree with using libraries were we can.

[dtkav]

Here's a branch with jsonref https://github.com/dtkav/connexion/tree/jsonref
Playing around with it a little bit, I don't think we actually want lazy evaluation. Also, the tests run _really slowly_.

Each resolve_reference call is doing two things:

1. Resolving json references at the provided "view" into the spec
2. Attaching definitions to that view["schema"] to be passed to the json validator

Because the json validator can already follow recursive references, I think we just need to resolve the references once (not recursively) early on, and then continue to attach the definitions for the various "views" into the spec (ex. body_schema).

I'll keep playing around, and hopefully put up a PR for discussion tonight, or early next week.

[rafaelcaricio]

I think we need to investigate why it is so slow. I will try to take a look at this branch you setup to investigate.

[dtkav]

I've included a PR that leverages the jsonschema RefResolver.
After playing with the lazy reference resolver, I don't think it's a great idea anymore.

This above PR will instead resolve the spec early on (right after validation), but still provides recursive schema validation by allowing definitions to be "attached" to a schema, providing a "view" into the spec that is self-contained.

An example of a "view" would be something like a body schema.

[dtkav]

hey @rafaelcaricio or @jmcs can you take a look at #627 ? I think that's the last architectural change that I can think of to make the oas3 branch cleaner, and then I'll probably start looking to merge that. Thanks!