Added fixes to Token Handling

[NickolausDS]

Previous implementation did not properly do token introspection on
incoming tokens due to them being the wrong token type. The new
implementation only accepts tokens from the minid defined scope.

[NickolausDS]

The GLOBUS_AUTH_ENABLED config option was removed. Not including a Client ID or Secret does effectively the same thing.

[ericblau]

I find it slightly confusing in minid_server/api/utils.py that
when you do:
code = authorization_header.split()
the variable code actually contains the bearer token that you later introspect, doesn't it? Thus I'd prefer "token" as a variable name, or something similar.

[NickolausDS]

the variable code actually contains the bearer token that you later introspect, doesn't it? Thus I'd prefer "token" as a variable name, or something similar.

Good point! I also notice that type is used as a variable name which also bothers me now that I look at it, I'll change both var names.

[NickolausDS]

Originally this was set to username, which isn't what we want. Sometimes usernames match up with emails, but not always. One example is Globus IDs, which could have a user with the id of malcomreynolds@globusid.org and email of malcomr@globus.org.

[NickolausDS]

@kylechard Question for you: do you know how many users are using the old auth tokens? The NIH Commons project just got setup to use them, and I'm not sure how many more folks are also using the old system. For those users these changes are breaking (although the only thing they need to do is switch their servers to request the minid scope, and re-login with their minid clients).

An alternative is we still allow the old token functionality for the time being and have the minid client log a deprecation warning when someone tries to use it.