Redirect URI comparison for native OAuth clients (RFC 8252)

[lionick]

Native Applications have to use ephemeral ports in the redirect_uri. This is something that is already addressed by the RFCs:

Draft-ietf-oauth-security-topics-27: This document therefore advises simplifying the required logic and configuration by using exact redirect URI matching ... The only exception is native apps using a localhost URI: In this case, the authorization server MUST allow variable port numbers as described in [RFC8252], Section 7.3.

RFC 8252: OAuth 2.0 for Native Apps (rfc-editor.org): Native apps that are able to open a port on the loopback network interface without needing special permissions (typically, those on desktop operating systems) can use the loopback interface to receive the OAuth redirect. Loopback redirect URIs use the "http" scheme and are constructed with the loopback IP literal and whatever port the client is listening on. That is, "http://127.0.0.1:{port}/{path}" for IPv4, and "http://[::1]:{port}/{path}" for IPv6.

[c00kiemon5ter]

We have discussed these changes with @lionick
and the implementation works.

The changes are contained within verify_uri function.
The changes come with tests for different cases where this aspect can come up.

The rest of the changes are about making sure the right application type is used, by using a variable rather than duplicating strings. I think that this is better and keeps the codebase tidier.

There is a failing test that is not related to this PR. A dedicated issue highlights this - see #106

[lionick]

@rohe I have also rebased this PR.