API design rule support

[GeoSander]

Overview

This PR adds an optional api_rules object to the server section of the pygeoapi configuration (YAML). For an example, please check the updated documentation here. Explanation about the available options can be found here.

The suggested changes affect the API at the highest level (Flask, Starlette, Django). Because the current tests only test the lower level methods in api.py but not the routes leading towards them, I have added a mock client for Flask and Starlette so we can test API rule adherence or any routing-related things for that matter.

Note that I have also replaced the @app.route() decorators in favor of Route() in starlette_app.py. This technique was deprecated anyway (it is not even documented anymore in the current Starlette docs) and it proved harder to build in the API rule logic like that.

Related Issue / Discussion

This PR relates to issue #1134, which contains the rationale behind this change.

Additional Information

Since this work is part of a funded tender in which Geonovum emphasized that it was very important to them that the work would be incorporated into the core, and also because the suggested changes are optional and non-disruptive, we hope that the community is willing to approve this PR.

Contributions and Licensing

(as per https://github.com/geopython/pygeoapi/blob/master/CONTRIBUTING.md#contributions-and-licensing)

• I'd like to contribute feature "API design rule support" to pygeoapi. I confirm that my contributions to pygeoapi will be compatible with the pygeoapi license guidelines at the time of contribution.
• I have already previously agreed to the pygeoapi Contributions and Licensing Guidelines.

[tomkralidis]

See change requests. Adding @francbartoli given the significant changes to starlette.

[GeoSander]

Thanks for looking @tomkralidis.
As for the "significant changes to Starlette" (@francbartoli), it's really not that significant except for the changes that were also done for Flask and Django. I mostly refactored the routing to follow a more fashionable approach, so I could better fit in the actual changes I needed to do.

[GeoSander]

Thanks for reviewing @francbartoli!

[GeoSander]

Hi @tomkralidis / @francbartoli, I added the final changes (Starlette mock client, more tests) as per your request.

For Starlette, I ran into an interesting problem. Flask has a strict_slashes=True setting, which will prevent it from redirecting (308) to the URL without a trailing slash if the user added one and throws a 404 instead. Exactly what I needed. Starlette however has the redirect_slashes setting, but that only prevents the redirection (307) from happening and does not enforce strictness: adding a trailing slash will simply result in a 200 most of the time, and in some cases it still redirected anyway...

So I have now added a middleware class that tackles this problem. Note that the middleware is only installed when the strict_slashes API rule applies.

Please review at your earliest convenience. @justb4 and I officially have a deadline this Friday, but if merging cannot be achieved before that time, I guess we could merge it to some temporary project branch instead.

Changes were implemented in the meantime

[GeoSander]

Changed behavior of landing page requests according to OGC spec here if the strict_slashes API rule is in effect. For the landing page only, having a trailing slash is actually preferred (or mandatory even).
Note that this actually contradicts the Dutch API Design Rules as discussed here, which simply states that trailing slashes are never allowed.

[GeoSander]

Update: rebased again to incorporate latest changes to collection_items route in starlette_app.py (added OPTIONS HTTP method).