SSO integration

[VoxSecundus]

This PR introduces a level of integration with a valid Flight SSO server for authentication with Flight Control.

Prerequisites

A new key must be set in config/environments/*.rb for the URL/port to access the SSO server. In both development and production, the SSO cookie name can be inferred from the SSO_COOKIE_NAME environment variable. The JWT_SECRET environment variable must also be set, matching the SSO environment you are using.

Schema migration

Users now have an optional flight_id field. This field is used as a foreign key to associate users in the Flight Control database with users existing in the Flight SSO database.

Although the email field on users was added in a prior PR, it is only now being used so that both the username and email of an SSO user can be stored.

Functionality

Signing in

When a user with no session token for Control logs in for the first time, their credentials are pinged to the SSO server to see if they have a valid SSO account. If so, and this is the first time they have logged into Flight Control, a user entity is created in the Control database. If it isn't the first time they've logged into Flight Control, the existing user is signed in.

If the user doesn't exist as an SSO entity, then the 'local' user strategy is attempted, with standard behaviour commencing from there.

Session tokens

If a user has an SSO session token in their browser (containing a valid JWT), they are automatically signed in to Flight Control. As with signing in, if their user has no Flight Control entity, one is created automatically.

If a user happens to have both a Flight Control session and an SSO session in their browser, the Flight Control session is prioritised.

[VoxSecundus]

This is ready for another look now.

[VoxSecundus]

In the most recent commit, the sso_uri config key was changed to no longer need (and in fact, only function without) the /sign-in path so that the new SSO sync task can be run.