Authentication framework refactor

Description

Remember sso? This is it now. Feel old yet?

This branch contains the good parts of the old sso branch, namely the authentication framework refactoring and setting key implementation.

The SAML stuff has been removed from the core, with the possibility of reintroducing these features as a plugin later on in mind (therefore it seems unwise to delete the sso branch until an actual plugin has been created). But that is all for the future, and the future is not now. The refactoring is now, and that is what you are looking at.

Keep in mind that !127 (merged) also contains further improvements, such as a builder for Auta users. Also remember that you already reviewed most of this previously and your questions may have been answered in !100 (closed).

Changes and additions, abridged

Authentication database

• Automatic migrations to newer versions
• Automatic backups before migrations are applied
• Interfaces to generify database operations (not actually used, this is a remnant of SAML, but a very nice remnant at that)

Authentication model

• AutaUser, a custom User implementation for our pleasure
• DatabaseConnection prefers AutaUsers over Users
• Display names for users, better than netids or email addresses (or, for SAML, funky URIs, but that no longer applies obviously)

Settings

• An enum for setting keys
• Base path resolution

Controllers

• Sadly, all API action mapping annotations now need to contain a produces = MediaType.<TYPE>_VALUE or else Spring will output it as XML, even though I told it not to. It's gotten to the point that I am looking for a relationship therapist, because this marriage ain't working no more, Spring. !127 (merged) contains a sanity checker that checks, at startup, for unannotated actions.

Test and Review

To be filled in by the reviewers

• All of the methods are commented to expectation

• The methods are tested to satisfaction

• There are no unnecessary files present in the MR

• The continuous integration has no problems with the MR

• The MR is filled in as requested (including labels, milestones, and reviewers)

• The documentation is up-to-date

• All nullable parameters are marked as such