Store username and barcode in hashed form

[courte]

We need to be able to look up a Patron record given username and barcode, but (once https://jira.nypl.org/browse/SIM-59 is complete) we never need to display username or barcode unless we just got it fresh from the ILS. This means we can store Patron.username and Patron.barcode in hashed form, eliminating a bit of plaintext PII from our dataset.

Transferred from Jira.

[aslagle]

I started looking into how to do this a while ago:
4552a33

[leonardr]

There is one case when we do need plaintext username and barcode: when Adobe uses a temporary token to authenticate as a patron and asks for the human-readable label. We're reevaluating this work in light of this discovery.

[aslagle]

Here are the hashing changes anyway:
https://github.com/NYPL-Simplified/circulation/tree/hashed_identifiers
https://github.com/NYPL/Simplified-server-core/tree/hashed_identifiers

[jce1028]

Currently Barcode or username are not required to be encrypted. However, as a best practice, encrypting them in transit and at rest in the DB would be beneficial so we don't have query the ILS repeatedly for a piece of information it is not required to encrypt.

[leonardr]

Given that this was a nice-to-have that actually causes problems for patrons, I'm closing this issue.

[jce1028]

Given the never ending excuse to not release or classification of SimplyE as "High Risk" lets opt to be unimpeachable.

[leonardr]

Given that SimplyE has been released for a while, and this change would still cause problems for patrons, I'm re-closing this issue.