Rework auth to include scopes as well as groups

[ssalinas]

The previous setup was originally meant for a very simple auth scheme. We now need a bit more granularity, since a set of groups only allows us to do things at a mostly global level for permissioning.

This PR initially refactors the authorization helper to an interface with a groups as well as a groups+scopes implementation. Still TODO:

• Actually write the groups + scopes authorizer
• Unit tests for ^^
• Wire up an operation mode for the groups and scopes authorizer or additional implementation that logs one and falls back to the other. Ideally we could do something like be able to run the new code and old code at once and just log if they are different. This may or may not be possible easily since they would have separate api endpoints for webhooks
• Wire up jita with increased logging for all jita-ed actions

cc @pschoenfelder

[ssalinas]

@pschoenfelder mind taking a look on this one? Biggest open question I have is if we should keep the defaultReadOnlyGroups config around or not. Need to check if our setup is creating requests with top level groups as the default read only, or if Singularity is adding that right now. Not sure if we want that default behavior to be that permissive (though it is current I guess)

[pschoenfelder]

Looks like this and several other methods below follow the same patten of checkGrantedByScopes -> check groups authorizer -> maybe warn. Is there a way to factor the pattern out?

[ssalinas]

yeah, I can take another pass at slimming it down after I do a few initial tests in staging. Did one pass already to factor some things out, but I think you're right that I can DRY it up a bit more

[pschoenfelder]

Looks good to me. Nice unit tests 👍 Always happy to see that. As far as removing defaultReadOnlyGroups goes, I would lean towards keeping it, at least for now while these changes get rolled out.

[ssalinas]

Bug in here somewhere still, dual authorizer returned all 401s on staging

[pschoenfelder]

🚢