Uaa token provider

[tareksha]

Current it is complicated to extend or mock AbstractUaaTokenProvider because it is locked by final and package-protected methods. Add an intermediate interface for UAA token providers to allow extending and mocking the UAA functionality more elegantly.

[cfdreddbot]

:x: Hey tareqhs!

All pull request submitters and commit authors must have a Contributor License Agreement (CLA). Click here for details on the CLA process.

The following github user @tareqhs is not covered by a CLA.

After the CLA process is complete, this pull request will need to be closed & reopened. DreddBot will then validate the CLA(s).

[nebhale]

Can you give an example of extension and mocking that you're trying to do where the TokenProvider interface isn't sufficient? The class is designed for extension and locks down certain methods that shouldn't be overridden as they define the core behavior of the class.

[tareksha]

@nebhale We have a solution that makes use of UAA-specific token data, e.g. refresh tokens. Writing wrappers and unit test is overly complicated because getToken() is locked with final and forces me to go through HttpClient flows. Also the two abstract methods are package-protected and force me to put the relevant code inside a package that is irrelevant to the project ( org.cloudfoundry.reactor.tokenprovider ).

Locking the code that much makes it actually less extensible.