Refactor client authentication

[nsklikas]

This PR introduces various changes to the client authentication flow. I believe that with these changes the flow is cleaner. This PR changes:

• Add client_authn_methods per client and per endpoint.
• The client_authn_methods of a client MUST be a subset of the endpoint's client_authn_methods.
• Change none client_authn_method to require a client_id in the request. This may be breaking in the case of the session endpoint. Perhaps a different authn class is required there.
• Refactor raised errors.

TODO:

• [ ] Document client_authn_method per client
• [ ] Should we allow the client_authn_methods of a client to allow methods not allowed in the endpoint. The problem with implementing this is that we don't know the client before we authenticate it, which would force us to have some brute force approach that would check all the client authn methods, find one that works and then check that it is allowed for this client/endpoint, if not then we continue looking for a client authn method that works

[rohe]

I don't see the need for using @classmethod. Please enlighten me. Unless used in a factory context (which this isn't) I think using classmethod is more of a optimisation. Something we usually don't regard as a main objective. We also doesn't use this pattern in other places so adding it here will just confuse developers. I think we'd better use the pattern that are present in oidcmsg and not introduce classmethod when not needed.

[nsklikas]

@rohe I used classmethod to avoid having to initialize the class and use it as a singleton. I removed client_auth_setup for this reason, if you think that it would cause confusion then I shall change it back.

[rohe]

@nsklikas I think it will. So please do !

[nsklikas]

I would also like your opinion on another big change happening in this PR. In the past the none authn method would allow requests without a client_id. Now this changes.

Do you think there is a use case were we should allow such requests? The only one I can think of is for the registration endpoint. Still if we want to support this behavior I think the following change is needed: Separate the logic of the none authn method by introducing another authn method, let's call it public. The difference between none and public is that, in public, client_id will be mandatory. This approach would have the upside of not introducing any breaking changes (i.e. changing the behavior of none).

What do you think @rohe @peppelinux?

[rohe]

The none authn method was added for testing purposes and should never ever be used in production. Having said that I know that people uses whatever is provided in whatever way they find reasonable. That's life :-/

Anyway, I'm perfectly OK with adding public beside none as per your proposal.