Store LTIUser & HUser data in LMS's DB

Both LTIUser and HUser are currently NamedTuple models but are not persisted on the DB

Store all the info currently held at runtime by LTIUser and HUser into one or two DB tables

Related tickets:

https://github.com/hypothesis/lms/pull/3067

What are we going to store?

From LTIUser:
- user_id
- oauth_consumer_key and tool_consumer_instance_guid - As application_instance.id
- roles
- display_name - No. Personally identifying
- email - No. Personally identifying
- From HUser:
- username - This is the hashed ID. Very important
- display_name - No. Personally identifying and redundant - This is the same as LTIUser.display_name
- provider - No. Redundant - This is the same as LTIUser.tool_consumer_instance_guid
- provider_unique_id - No. Redundant - This is the same as LTIUser.user_id

Final list:

LTIUser.user_id
LTIUser.oauth_consumer_key and LTIUser.tool_consumer_instance_guid as application id
LTIUser.roles
HUser.username

When is user data available?

Users objects are created in three scenarios we've spotted so far:

LTI param deserialisation in a schema
OAuth pararm deserialisation in a schema
During bulk actions (might be Canvas specific?)

The first two could probably be intercepted in h.secutity in a single place?

How are we going to store it?

One approach is to simply store the information. This would mean it was available in the DB, but wasn't necessarily available at run time.

Another approach is to make sure the user data is updated and returned for the application to inspect. At the moment this wouldn't result in any information the app doesn't already have. But it would be extremely useful if we chose to add user preferences one day. This could be in a user service which you provide details and it gives you back a user object. As a side effect it also updates the data creating a record. At the moment this "side effect" would be the only effect we are interested in, but it would stage us well in the future.

hypothesis / lms