make User a first-class object

[bcipriano]

Usernames are currently stored in the database as strings, in tables that have user info attached:

• job
• job_history
• owner
• comments

IMO users should be a first-class object in OpenCue, with a user table, and referenced by primary key in other tables.

This would allow us to expand the user definitions and add more metadata associated with each user. For example email address - see https://github.com/imageworks/OpenCue/issues/56 - as the current code assumes that all users share an email domain.

[bcipriano]

A few things that have come up recently that are worth mentioning here:

1. This would also unblock adding a permissions model to OpenCue. Specifically, limiting users to certain shows/projects has come up a few times.

2. There are a good number of users out there that already have some database of their local users e.g. Active Directory. Once Users exist in OpenCue we could look at how to sync such a setup with OpenCue.

[bcipriano]

As part of this feature, we should implement a check which blocks use of the system for users that do not exists.

In order to preserve the current behavior for users who prefer the current fully-trusted system, we should provide a "create users if they don't exist" type of option.

[bcipriano]

Some initial thoughts on how to start here:

1. Add a Cuebot property which determines whether the user system is enabled at all. For now, off by default.
2. Create a new User table in the database with username/hashed password fields.
3. Add a Cuebot API to perform user login. If username/password matches what's in the database, returns success. If not, fails with a permission denied error. Later on, this will be extended to return an auth token (or similar) to be used in followup API requests.
4. The above login API must provide a hook for external authentication systems -- we don't want to force users to manage two sets of users if they already have such a system.
5. Create an API for external authentication systems to add new users to the system.
6. When CueGUI or CueSubmit are launched, if the user system is enabled, display a dialog for entering username/password which calls the new Cuebot API. If an external authentication system is used, just use the system username.
7. Add plugins to CueGUI for viewing the user list and adding new users. If an external authentication system is used, it should be impossible to add new users.

This intentionally maintains the current "open system" model, and does not deal with any user permissions. It also does not handle any email configuration. These will be handled separately.