Add add_middleware interface

[RobbeSneyders]

This PR adds an add_middleware method to the apps and ConnexionMiddleware to easily add middleware to the stack. Before, the only way to do this was to pass in a complete middleware stack.

The default position to add the new middleware is right before the ContextMiddleware, which is the final middleware in the stack. Another position can be selected by passing in a MiddlewarePosition enum, which defines some positions which make sense.

Since we can no longer assume that the whole middleware stack is defined when initializing the ConnexionMiddleware, we need to delay building the middleware stack until the ConnexionMiddleware is actually called. This also means we need to delay registering the APIs and error handlers. This is now all done in the _build_middleware_stack method.

[RobbeSneyders]

These tests only test if the resolver becomes available as api.resolver, which doesn't really seem that useful.

[Ruwann]

Well, it's good to be sure that it's actually the resolver that was passed in 😅 But seems indeed too trivial to have a test for it

[RobbeSneyders]

Yes and add_api no longer returns the same API object. So it's not as easy to test this anymore. I see we don't have an integration test for this either though, I'll add one.

[RobbeSneyders]

We do already have integration tests for this in test_resolver_methodview.py, so will merge as is.

[coveralls]

Pull Request Test Coverage Report for Build 4686618629

• 36 of 43 (83.72%) changed or added relevant lines in 3 files are covered.
• 8 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.3%) to 93.583%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
connexion/middleware/main.py	32	39	82.05%

Files with Coverage Reduction	New Missed Lines	%
connexion/apps/abstract.py	1	90.91%
connexion/middleware/main.py	7	80.15%

Totals
Change from base Build 4646044651:	-0.3%
Covered Lines:	3354
Relevant Lines:	3584

---

💛 - Coveralls

[Ruwann]

LGTM! Makes me think of the Starlette implementation a bit - I wonder whether the same middleware class makes sense here as it does seem elegant.

[Ruwann]

Well, it's good to be sure that it's actually the resolver that was passed in 😅 But seems indeed too trivial to have a test for it

[RobbeSneyders]

Yes, I went for this approach instead of leveraging the starlette Middleware class since I think:

• Just passing the middleware and options to add_middleware is a more user-friendly interface than having to wrap it into a separate class first
• partials are Python builtin functionality that cover our need for providing options as part of the middleware stack.

Happy to hear if you don't agree.