Preference authorization processor

[jimchamp]

Closes #8893

Prevents unauthorized access to patrons' preferences. Instead, patrons will be able to access their own preferences, while admins can access all patrons' preferences.

These changes include access to json and yml encodings of patron preferences, not just the preference pages.

Technical

A new processor was created to aid with authorization. The PreferenceProcessor, when handling a request for patron preferences, gets a reference to the authenticated User. If the request was unauthenticated, a 401 error is raised. Then, the processor checks if the User is the owner of the requested preferences, or is an admin. If neither are true, a 403 error is raised.

If all checks pass, or the request is not for preferences, the processor handles the request as per usual.

Testing

At a minimum, the following should be tested:

While logged out:

1. Should not be able to view any /people/{username}/preferences page
2. Should not be able to make json or yml preference requests

While logged in as a non-admin:

1. Should be able to view one's own preference page
2. Should be able to make json and yml preference requests for one's own preferences
3. Should not be able to view other patrons' preference pages
4. Should not be able to make json and yml preference requests for other patrons' preferences

While logged in as an admin:

1. Should be able to view any preference page
2. Should be able to make json or yml preference requests for any account

Other:

1. /account/preferences requests should be unaffected by these changes
2. Code paths that modify or read preferences should be unaffected by these changes

Special deployment notes

This is a new processor, so we should be vigilant when this is deployed, and ensure that pages not related to preferences are unaffected, etc.

Screenshot

Stakeholders